6:16 a.m.
On Mon, Mar 27, 2017 at 12:59 PM Radim Vansa <rvansa(a)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(a)redhat.com
> <mailto:rvansa@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(a)lists.jboss.org
> <mailto:infinispan-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa(a)redhat.com <mailto:rvansa@redhat.com>>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org <mailto:
infinispan-dev(a)lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev