[infinispan-dev] Branching proposal

Sebastian Laskawiec slaskawi at redhat.com
Mon Mar 27 07:16:21 EDT 2017 

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

> On 03/27/2017 12:45 PM, Sebastian Laskawiec wrote:
> > From my past experience, if a commit caused a conflict when merging,
> > we always asked the author to fix it and do the merge.
>
> I don't understand. The PR should be filed against 9.0.x, there're no
> conflicts. Merging the same against master results in conflicts - where
> should I resolve those?
>

I think we mean 9.1.x (the oldest maintenance branch). In that case you
should merge 0.9.1 into 0.9.2. Than another merge 0.9.2 into master.

Once the conflict occurs, a developer who does the merge should simply
resolve it.


>
> Another q: I decide to file a PR against 9.1, because I don't think it
> should be applied to 9.0. I get a review, but then someone explains that
> it should get to 9.0 as well. I can't change a target branch in GitHub's
> PR: should I close the PR with nice history of comments (some of them
> not addressed yet) and open another PR?
>

You can do both (if depends on your intuition which is better). The nice
thing about git merge is that it won't throw any error if a change is
already present on target branch. So it is possible and legal to
cherry-pick stuff as well.


>
> R.
>
> >
> > 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
> > <mailto: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
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >     --
> >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> >     JBoss Performance Team
> >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > 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/f5952e26/attachment.html

More information about the infinispan-dev mailing list