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
