[infinispan-dev] Branching proposal
Radim Vansa
rvansa at redhat.com
Mon Mar 27 08:41:00 EDT 2017
On 03/27/2017 01:16 PM, Sebastian Laskawiec wrote:
>
>
> On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rvansa at redhat.com
> <mailto: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.
I am lost - we won't have 9.0.x as maintenance branch starting with
9.0.0.Final and 9.1.x == master moving towards 9.1.0.Final? What's 0.9.1
and 0.9.2?
>
> Once the conflict occurs, a developer who does the merge should simply
> resolve it.
You haven't explained *where*. I am a contributor, I don't "merge"
stuff, I file PRs. So, I'll do a PR against [maintanance branch] with
commits that can't be merged against [master] because these have
conflicts. This is one PR (against [maintenance branch]). Should I issue
another PR? With backports I wait until it gets into master (and usually
somebody requests the backport), how do I make sure that it gets into
master ASAP?
>
> 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>
> > <mailto: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>
> > <mailto: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>
> <mailto: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>
> <mailto: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
> <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
More information about the infinispan-dev
mailing list