On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <galder(a)redhat.com> wrote:
Why are we working in 9.1.x, 9.2.x and master in paralell? We
normally
work on master and maybe one more maintenance branch.
Except for occasional tricky backports (e.g. Radim's work) the rest has
been pretty straightforward for me. Also, the number of backports I work on
is low in general.
+1 For me the hard part is just remembering it needs to be backported. And
as Sanne mentioned refactorings shouldn't really be backported and these
are the types of the things that cause the most conflicts. And to be honest
on some backports I might not pull every change since the real fix may have
been quite small.
Cheers,
--
Galder Zamarreño
Infinispan, Red Hat
> On 27 Mar 2017, at 11:33, Sebastian Laskawiec <slaskawi(a)redhat.com>
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
>
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