Re: mimic is forked

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sage,

On 05/04/2018 04:57 AM, Sage Weil wrote:

> The mimic branch is now forked off of master, and the first release 
> candidate (13.1.0) is getting built.

Congratulations :)

> It's now possible to merge new stuff for nautilus into the master branch!
> 
> As for how we manage the mimic branch going forward, we have two options:
> 
> 1) Merge bug fixes to master and cherry-pick -x them to mimic.  This is a 
> bit of extra work, but it's what we're used to doing for the stable 
> releases after they're out.
> 
> 2) Merge bug fixes to mimic and periodically merge mimic back into master.  
> At some point we'll switch back to option 1 (e.g., when we declare vistory 
> and release 13.2.0).  This is a bit less work now, but means we'll switch 
> "modes" for how we're managing branches again in a few weeks and confuse 
> people.
> 
> I retargetted all the mimic branches at the mimic branch (i.e., option 2) 
> but I'm sort of thinking option 1 is less confusing.  Any strong opinions?

Doing 1) (cherry-picking fixes from master into a separate, long-lived
release branch) appears to be a more scalable approach, as it moves the
burden of resolving potential merge conflicts from one individual that
merges the release branch back into master to several individuals
performing the cherry-picks. However, it also results in greater
deviation of these branches in the long run, making cherry-picking fixes
from the master branch more and more difficult over time. It also
results in duplicate changesets and make it harder to look up the
history/origin of a bug fix (I'm aware that cherry-picks still refer to
the original commit in master, but there's do direct relation in the
commit history).

IMHO, the point of creating a release branch should be two-fold:

1. To make sure that new feature development work can continue
   uninterrupted in the master branch
2. To stabilize a release for publishing, by running additional tests
   and QA and fixing eventual bugs discovered in this process

I'm usually more a fan of 2), as it's less error-prone in the sense of
minimizing the risk of forgetting to backport/cherry-pick certain bug
fixes into the stable release and to improve the turnaround time in case
we need to fix critical bugs in released versions (as the fix is
actually done on the version that affects users first).

In fact, instead of having a permanently disconnected "mimic" branch or
doing periodic merges, I'd actually be in favor taking inspiration from
the OneFlow model [1], in which short-lived release branches always get
merged back into the master branch once a release has been stabilized,
tagged and published. You could still combine this with cherry-picking
selected bug fixes or features that have already been pushed into the
master branch when preparing a bugfix release of a stable version.

This would address both of the concerns that Kefu and Ricardo raised:
"easier to have every commit in a single branch, especially if some new
feature depends on a bug fix done for a stable release" as well as it
being simpler and less confusing model.

Lenz

[1] http://endoflineblog.com/oneflow-a-git-branching-model-and-workflow
-- 
SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux