[infinispan-dev] Branching proposal

[Sebastian Laskawiec]

>From my past experience, if a commit caused a conflict when merging, we
always asked the author to fix it and do the merge.

After a while it became a habit that each dev who submitted a code that
could result in conflicts, did all the merges.

On Mon, Mar 27, 2017 at 12:37 PM Radim Vansa <rvansa at redhat.com> wrote:

> If you can't merge a commit (based on 9.0.x) to master clearly, do you
> need to file another PR anyway? Then the lag to get some code to master
> increases a lot. I am not sure how useful is git tag --contains <sha1>
> if you cannot be sure that you'll find all occurrences due to this kind
> of issues.
>
> R.
>
> On 03/27/2017 11:33 AM, Sebastian Laskawiec 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170327/4d121ae8/attachment.html