[keycloak-dev] Commits/PRs

Fri Mar 11 09:12:21 EST 2016

That's a very unhelpful and unnecessary comment. If you don't care, don't
comment. If you object, then comment. To me this is important so there's no
reason to be condescending.

The process I described will be helpful for a number of reasons, including:

* It will make it simpler to maintain 1.9.x branch for product while we
move on to 2.x branch
* Users can search for JIRA issues to see if an issue they are having has
been fixed
* Users can view changes for a particular release, including descriptions
of why it was changed (maybe the change causes problems for them)
* Developers can figure out why something was done (2 years after it was
done)
* We can plan when to fix a bug. Not all bugs need fixing, some can be
postponed others are blocking for a release
* ....

In summary all I ask is squash commits and include KEYCLOAK-XXXX in the
commit message.

On 11 March 2016 at 14:55, Bill Burke <bburke at redhat.com> wrote:

> unsubscribe.  This is about as interesting as code formatting rules.
>
>
> On 3/11/2016 8:45 AM, Peter Palaga wrote:
>
> Hi Stian, inline...
>
> On 2016-03-11 06:53, Stian Thorgersen wrote:
>
>
>
> 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.
>
> Yes, I fully agree that the linking from Jira to GitHub makes sense.
>
> * 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.
>
> No, the explanation why the given commit was necessary may well be placed
> in the commit message itself. In many projects, this is the default place
> for that kind of info. Now, given that the motivation for the change can be
> described in the commit message, the overhead of creating a Jira needs to
> be justified. Writing the "why" to the commit message is much faster and
> more developer friendly than forcing contributors to create a Jira for
> every trivial improvement. I can say for myself that having to create a
> JIra before fixing some stupid bug substantially lowers my readiness to fix
> it at all.
>
> The work has to be scheduled the same as all other work.
>
> Yes, planning is fully legitimate within your team paid for the work but
> again, it sounds rather discouraging to me, an external contributor, when I
> just want to fix a malfunction in KC that blocks my primary task.
>
>
>> (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?
>
> Sure. This is the "normal" way, where tags 0.17.Final and 0.16.Final are
> *inside* a branch (master branch in this case):
>
>
> To get the tags from upstream, I do not need to use --tags with git fetch,
> because the in-branch tags are fetched also without --tags. Furthermore I
> can clearly see what happened between the yellow labels 0.17.Final and
> 0.16.Final.
>
> OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x branch
> I get only this:
>
>
> No tags there. Only some hints like "Next is 1.9.2" where the tags are
> perhaps around. Nevermind, I know I have to fetch with --tags:
>
>
> Still no tags there, because they are out of the 1.9.x branch that I have
> checked out. To see them, I have to "Show all branches and tags" in egit.
> Sadly, that brings also master and other branches, that I do not want to
> see, but let's try to ignore them, and have a look at what happened between
> 1.9.0.Final and 1.9.1.Final:
>
>
> While it is relatively easy to find out how 1.9.1.Final tag relates to
> 1.9.x branch, I am completely lost on the other end: 1.9.0.Final is a long
> fork of 1.9.x that I cannot track down visually at all. If 1.9.0.Final and
> 1.9.1.Final tags were a part of 1.9.x history, my eyes would be much
> happier. That's it.
>
> Thanks,
>
> -- Peter
>
>
>
>>
>> (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>
>> 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,
>>>
>>>
>>
>
>
>
> _______________________________________________
> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> --
> Bill Burke
> JBoss, a division of Red Hathttp://bill.burkecentral.com
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 20564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0004.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30074 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0005.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 30771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0006.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 102619 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/2160809c/attachment-0007.png 