[keycloak-dev] Commits/PRs
Bill Burke
bburke at redhat.com
Fri Mar 11 08:55:10 EST 2016
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
>> <mailto: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 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 list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/a9e12621/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/a9e12621/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/a9e12621/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/a9e12621/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/a9e12621/attachment-0007.png
More information about the keycloak-dev
mailing list