<div dir="ltr">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.<div><br></div><div>The process I described will be helpful for a number of reasons, including:</div><div><br></div><div>* It will make it simpler to maintain 1.9.x branch for product while we move on to 2.x branch<br></div><div>* Users can search for JIRA issues to see if an issue they are having has been fixed</div><div>* Users can view changes for a particular release, including descriptions of why it was changed (maybe the change causes problems for them)</div><div>* Developers can figure out why something was done (2 years after it was done)</div><div>* We can plan when to fix a bug. Not all bugs need fixing, some can be postponed others are blocking for a release</div><div>* ....</div><div><br></div><div>In summary all I ask is squash commits and include KEYCLOAK-XXXX in the commit message.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 March 2016 at 14:55, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
unsubscribe. This is about as interesting as code formatting rules.<div><div class="h5"><br>
<br>
<div>On 3/11/2016 8:45 AM, Peter Palaga
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div class="h5">
<div>Hi Stian, inline...<br>
<br>
On 2016-03-11 06:53, Stian Thorgersen wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 10 March 2016 at 22:17, Peter
Palaga <span dir="ltr"><<a href="mailto:ppalaga@redhat.com" target="_blank">ppalaga@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Stian,<br>
<br>
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.<br>
<br>
(1)<span><br>
> With JIRA key in commit and PRs linked in JIRA we
get a good history<br>
> that is useful in the future to identify what was
changed and why.<br>
<br>
</span> To see *what* was changed, I do not need to go
to Jira. Git history is the ultimate source of that
info.<br>
<br>
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?<br>
</blockquote>
<div><br>
</div>
<div>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:</div>
<div><br>
</div>
<div>* 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.</div>
</div>
</div>
</div>
</blockquote>
Yes, I fully agree that the linking from Jira to GitHub makes
sense.<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>* 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.</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote type="cite">The work has to be scheduled the same as
all other work.</blockquote>
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.<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
(2) I want tags in branches.<br>
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.<br>
<br>
Please consider tagging the usual way.<br>
</blockquote>
<div><br>
</div>
<div>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? <br>
</div>
</div>
</div>
</div>
</blockquote>
Sure. This is the "normal" way, where tags 0.17.Final and
0.16.Final are *inside* a branch (master branch in this case):<br>
<img src="cid:part2.00040405.05020902@redhat.com" alt=""><br>
<br>
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.<br>
<br>
OTOH in KC, when I forget to fetch with --tags, switching to 1.9.x
branch I get only this:<br>
<img src="cid:part3.09060304.03040902@redhat.com" alt=""><br>
<br>
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:<br>
<img src="cid:part4.04070602.08000201@redhat.com" alt=""><br>
<br>
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:<br>
<img src="cid:part5.02000405.05070306@redhat.com" alt=""><br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
-- Peter<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
(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:<br>
* upgrades of dependencies<br>
* refactorings<br>
* various formatting and license header fixes<br>
I hope most of you will agree here.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>For minor documentation updates (grammar, spelling
fixes, etc.) or minor pure formatting sure they don't
need a JIRA.</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
(4) Pro tip for Chrome users:<br>
I created a content script that makes Jiras and BZs on
GitHub clickable links. This is what it looks like: <a href="http://snag.gy/rq6Ja.jpg" target="_blank"></a><a href="http://snag.gy/rq6Ja.jpg" target="_blank">http://snag.gy/rq6Ja.jpg</a>
How to install: <a href="https://goo.gl/bYUbHS" rel="noreferrer" target="_blank">https://goo.gl/bYUbHS</a><br>
<br>
Thanks,<br>
<br>
Peter
<div>
<div><br>
<br>
On 2016-03-10 19:12, John Dennis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 03/10/2016 01:03 PM, Bill Burke wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is there a way to
automatically squash everything to your latest<br>
commit?<br>
</blockquote>
<br>
Maybe not automatically, but the conventional way
to squash commits is<br>
with interactive rebase, e.g.<br>
<br>
% git rebase -i commit<br>
<br>
where commit is the commit id of the *prior*
commit you want to start<br>
the squashing from. Git will fire up your defined
editor and you just<br>
replace the pick keyword with the squash keyword
for each commit to be<br>
squashed. Many examples on the web. It's not
automatic but usually less<br>
than a minute from start to finish.<br>
<br>
HTH,<br>
<br>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</span></blockquote>
<br><span class="">
<pre cols="72">--
Bill Burke
JBoss, a division of Red Hat
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a></pre>
</span></div>
<br>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br></blockquote></div><br></div>