Ok, I think I can try to sum this proposal and discussion up: - The proposal doesn't fit well into our workflow. - We are more focused on developing in master branch and do occasional (and sometimes partial) backports. - We use at most one maintenance branch, so there's no big deal. - 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.
Thanks a lot guys for all the input! Cheers, Sebastian On Tue, Mar 28, 2017 at 3:56 PM William Burns <mudokon...@gmail.com> wrote: > On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <gal...@redhat.com> > wrote: > > 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. > > 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. > > > +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. > > > > Cheers, > -- > Galder Zamarreño > Infinispan, Red Hat > > > On 27 Mar 2017, at 11:33, Sebastian Laskawiec <slask...@redhat.com> > wrote: > > > > Hey! > > > > We are about to start working on 9.1.x and 9.2.y branches so I would > like to propose alternative merging strategy. > > > > Our current workflow looks like this: > > > > X - new commit > > X` - cherry pick to maintenance branch > > --+-------------------+-------X----- master > > | \------X`---- 9.2.x > > \---------------------------X``--- 9.1.x > > > > 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). > > > > The proposal: > > > > X, Y - new commits > > / - merge commits > > --+---------+------/----/--- master > > | \----/---Y/---- 9.2.x > > \-------------X/---------- 9.1.x > > > > 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: > > • Merging commits should be performed very often (even > automatically in the night (if merged without any problems)). > > • 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. > > • 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. > > • 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. > > 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). > > > > Thanks, > > Sebastian > > _______________________________________________ > > infinispan-dev mailing list > > infinispan-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
