[keycloak-dev] Commits/PRs
Peter Palaga
ppalaga at redhat.com
Fri Mar 11 08:45:50 EST 2016
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,
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iffagdhf.png
Type: image/png
Size: 20564 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0004.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icddedjg.png
Type: image/png
Size: 30074 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0005.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ehadefhf.png
Type: image/png
Size: 30771 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0006.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: egdifcbj.png
Type: image/png
Size: 102619 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160311/bcc5ffb2/attachment-0007.png
More information about the keycloak-dev
mailing list