[infinispan-dev] Branching proposal

[Sebastian Laskawiec]

Ok, I think I can try to sum this proposal and discussion up:

   - The proposal doesn't fit well into our workflow.
   - We are more focused on developing in master branch and do occasional
   (and sometimes partial) backports.
   - We use at most one maintenance branch, so there's no big deal.
   - Dan's one-liner (`git tag --contains $(git log --grep <JIRA> -1
   --format="%h" master)`) very nicely replaces `git tag --contains <SHA1>`
   but as Galder mentioned, we should always use JIRAs.

Thanks a lot guys for all the input!

Cheers,
Sebastian

On Tue, Mar 28, 2017 at 3:56 PM William Burns <mudokonman at gmail.com> wrote:

> On Tue, Mar 28, 2017 at 9:27 AM Galder Zamarreño <galder at 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 at 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 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
>
> _______________________________________________
> 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/20170330/7962c5ee/attachment-0001.html