[infinispan-dev] Branching proposal

[Radim Vansa]

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?

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?

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