<div dir="ltr">Ok, I think I can try to sum this proposal and discussion up:<div><ul><li><font size="2">The proposal doesn't fit well into our workflow.</font></li><li><font size="2">We are more focused on developing in master branch and do occasional (and sometimes partial) backports. </font></li><li><font size="2">We use at most one maintenance branch, so there's no big deal.</font></li><li><font size="2">Dan's one-liner (`git tag --contains $(git log --grep <JIRA> -1 --format="%h" master)`) very nicely replaces `git tag --contains <SHA1>` but as Galder mentioned, we should always use JIRAs. </font></li></ul><div><font size="2">Thanks a lot guys for all the input!</font></div></div><div><font size="2"><br></font></div><div><font size="2">Cheers,</font></div><div><font size="2">Sebastian</font></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 28, 2017 at 3:56 PM William Burns <<a href="mailto:mudokonman@gmail.com">mudokonman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <<a href="mailto:galder@redhat.com" class="gmail_msg" target="_blank">galder@redhat.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why are we working in 9.1.x, 9.2.x and master in paralell? We normally work on master and maybe one more maintenance branch.<br class="gmail_msg">
<br class="gmail_msg">
Except for occasional tricky backports (e.g. Radim's work) the rest has been pretty straightforward for me. Also, the number of backports I work on is low in general.<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">+1 For me the hard part is just remembering it needs to be backported. And as Sanne mentioned refactorings shouldn't really be backported and these are the types of the things that cause the most conflicts. And to be honest on some backports I might not pull every change since the real fix may have been quite small.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Cheers,<br class="gmail_msg">
--<br class="gmail_msg">
Galder Zamarreño<br class="gmail_msg">
Infinispan, Red Hat<br class="gmail_msg">
<br class="gmail_msg">
> On 27 Mar 2017, at 11:33, Sebastian Laskawiec <<a href="mailto:slaskawi@redhat.com" class="gmail_msg" target="_blank">slaskawi@redhat.com</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> Hey!<br class="gmail_msg">
><br class="gmail_msg">
> We are about to start working on 9.1.x and 9.2.y branches so I would like to propose alternative merging strategy.<br class="gmail_msg">
><br class="gmail_msg">
> Our current workflow looks like this:<br class="gmail_msg">
><br class="gmail_msg">
> X - new commit<br class="gmail_msg">
> X` - cherry pick to maintenance branch<br class="gmail_msg">
> --+-------------------+-------X----- master<br class="gmail_msg">
> | \------X`---- 9.2.x<br class="gmail_msg">
> \---------------------------X``--- 9.1.x<br class="gmail_msg">
><br class="gmail_msg">
> Each commit needs to be reviewed in master branch and backported to the maintenance branches. From maintenance perspective this is a bit painful, since in above example we need to get 3 times through PR queue. Also it's worth to mention that X is not X` nor X``. Cherry-picking creates a copy of a commit. This makes some useful tricks (like git tag --contains <sha1>) a bit harder to use. Finally, this approach allows the codebase to diverge from maintenance branches very fast (someone might just forget to backport some of the refactoring stuff).<br class="gmail_msg">
><br class="gmail_msg">
> The proposal:<br class="gmail_msg">
><br class="gmail_msg">
> X, Y - new commits<br class="gmail_msg">
> / - merge commits<br class="gmail_msg">
> --+---------+------/----/--- master<br class="gmail_msg">
> | \----/---Y/---- 9.2.x<br class="gmail_msg">
> \-------------X/---------- 9.1.x<br class="gmail_msg">
><br class="gmail_msg">
> With the proposal, a developer should always implement a given feature in the lowest possible maintenance branch. Then we will run a set of merges from 9.1.x into 9.2.x and finally into master. The biggest advantage of this approach is that given functionality (identified by a commit) will have the same SHA1 for all branches. This will allow all tools like (mentioned before) `git tag --contains <sha1>` to work. There are also some further implications of this approach:<br class="gmail_msg">
> • Merging commits should be performed very often (even automatically in the night (if merged without any problems)).<br class="gmail_msg">
> • After releasing each maintenance release, someone will need to do a merge with strategy `ours` (`git merge -s ours upstream/9.2.x`). This way we will not have to solve version conflicts in poms.<br class="gmail_msg">
> • Since there is no nice way to rebase a merge commit, they should be pushed directly into the master branch (without review, without CI). After the merge, HEAD will change and CI will automatically pick the build. Remember, merges should be done very often. So I assume there won't be any problems most of the times.<br class="gmail_msg">
> • Finally, with this approach the code diverges slight slower (at least from my experience). Mainly because we don't need to remember to cherry-pick individual commits. They are automatically "taken" by a merge.<br class="gmail_msg">
> From my past experience, this strategy works pretty nice and can be almost fully automated. It significantly lowers the maintenance pain around cherry-picks. However there is nothing for free, and we would need to get used to pushing merged directly into master (which is fine to me but some of you might not like it).<br class="gmail_msg">
><br class="gmail_msg">
> Thanks,<br class="gmail_msg">
> Sebastian<br class="gmail_msg">
> _______________________________________________<br class="gmail_msg">
> infinispan-dev mailing list<br class="gmail_msg">
> <a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div></div>
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div>