[keycloak-dev] Commits/PRs

[Stian Thorgersen]

On 10 March 2016 at 22:17, Peter Palaga <ppalaga at redhat.com> wrote:

> Hi Stian,
>
> just a few minor points. Please note that I am speaking primarily from the
> standpoint of somebody who often looks into the history of KC branches,
> because Hawkular (where I am primarily active) uses KC. I am not a regular
> contributor to KC.
>
> (1)
> > With JIRA key in commit and PRs linked in JIRA we get a good history
> > that is useful in the future to identify what was changed and why.
>
> To see *what* was changed, I do not need to go to Jira. Git history is the
> ultimate source of that info.
>
> As for the *why*, the project has to coin some convention. From what you
> say it seems that it should be Jira, right? Yes, that is one of the
> legitimate choices, but not the only possible one. Git commit messages may
> serve the purpose too and I personally find them much more practical
> because they are much closer to where I usually start looking. Jira is
> usually one slooowly loading link further. Therefore, could you please
> explain why you find Jira better?
>

One isn't better than the other. They serve different purposes. Git commit
messages will tell you what code was changed, while JIRA descriptions will
tell you why it was changed. Both are equally important. Making sure you
can go from a JIRA issue to Git commits and the other way around are both
important. Imagine two examples:

* A user searches for a bug in JIRA to see if the problem he's having has
been resolved. He finds the issue and wants to take a look at what changes
was made to understand it better.
* A developer finds some code he wrote 12 months ago was changed, looks at
Git history to see who did it, but has no idea why. He then sees the JIRA
key in the commit message and opens it in JIRA. There he finds a lengthy
description of the bug, including several comments.


>
> (2) I want tags in branches.
> Your tags are outside branches (such as 1.9.x) and that makes it harder to
> clearly and quickly see what happened between e.g. 1.9.0 and 1.9.1. You are
> the second project doing it like this out of ~150 Java projects I have ever
> cloned.
>
> Please consider tagging the usual way.
>

You've certainly cloned more repositories than I have.. I'm not sure what
you mean. 1.9.x tags has to come from 1.9.x branch as master is now 2.x.
Can you elaborate?


>
> (3) While I agree that the linking between git history and Jira is useful,
> saying that every commit needs a Jira does not sound reasonable. There
> certainly are commits that do not deserve a Jira, such as:
> * upgrades of dependencies
> * refactorings
> * various formatting and license header fixes
> I hope most of you will agree here.
>

I disagree, I want a complete record of what's been done in JIRA. Upgrading
of dependencies should not just be done randomly. It has a reasoning behind
it (for example a security fix, or to re-allign with WF dependencies, or
whatever) without a JIRA you don't have that. Same goes for refactoring,
they either should be done as part of an existing JIRA or there should be a
JIRA describing why it was done. The work has to be scheduled the same as
all other work.

For minor documentation updates (grammar, spelling fixes, etc.) or minor
pure formatting sure they don't need a JIRA.

All rules come with exceptions, that's just the way of life. However, by
defacto all commits should have an associated JIRA. That's even more
important for external contributions.


>
> (4) Pro tip for Chrome users:
> I created a content script that makes Jiras and BZs on GitHub clickable
> links. This is what it looks like: http://snag.gy/rq6Ja.jpg How to
> install: https://goo.gl/bYUbHS
>
> Thanks,
>
> Peter
>
>
> On 2016-03-10 19:12, John Dennis wrote:
>
>> On 03/10/2016 01:03 PM, Bill Burke wrote:
>>
>>> Is there a way to automatically squash everything to your latest
>>> commit?
>>>
>>
>> Maybe not automatically, but the conventional way to squash commits is
>> with interactive rebase, e.g.
>>
>> % git rebase -i commit
>>
>> where commit is the commit id of the *prior* commit you want to start
>> the squashing from. Git will fire up your defined editor and you just
>> replace the pick keyword with the squash keyword for each commit to be
>> squashed. Many examples on the web. It's not automatic but usually less
>> than a minute from start to finish.
>>
>> HTH,
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/051dbd5d/attachment.html