Thank you all for the constructive and helpful comments! Cedric said what I did not dare to say openly: my stable branch was created too early, which is causing this need to do a merge (heck, I even needed a fast forward merge of my stable branch). I did not like it a bit that stable/euphrates was created at that commit but I could not do anything about it.
I agree that in normal circumstances, you would not do a merge due to the special nature of a stable branch. But in my case it just happens that my stable branch was created a few weeks ago, and since then about 40 commits went in master, many are doc update commits, some are bug fixes, some are minor enhancements that all make the master branch a lot more stable than my stable branch. Perhaps this will come back in our future discussion on how to integrate versioning, branching with XCI. But to close on this topic I think: * There are exceptions to every rule and in this case merge is the best option due to the special circumstances * Process and tools should not get in the way of projects and prevent valid exceptions to be dealt properly (here I am frustrated because I can’t even submit a merge commit to gerrit) * There is no additional risk in allowing merge commits to be submitted to gerrit because the committers can always reject the request Given I have to finalize my stable branch today, I had no choice but to cherry pick all 40 of my master commits into my stable branch, which results in a pretty ugly stable branch - when a fast forward merge would have achieved the same end result with exactly zero extra commit. But I’ll survive this ;-) Thanks to Trevor/Ross for their recipe on how to cherry pick/rebase both methods work very well (I ended up using Ross’ method of rebasing). It is likely this will repeat for 6.0 unless we introduce a more flexible release model with XCI. Or perhaps a stable branch will no longer be of important significance for my project given that the best and most stable version of my project will likely always live in another branch than the stable branch. There might be a generally conceived idea that a master branch is usually not stable, but that is not necessarily the case for every project. Thanks Alec From: "Yujun Zhang (ZTE)" <zhangyujun+...@gmail.com> Date: Friday, October 20, 2017 at 12:50 AM To: "Alec Hothan (ahothan)" <ahot...@cisco.com>, Trevor Bramwell <tbramw...@linuxfoundation.org> Cc: "opnfv-tech-discuss@lists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] [releng] How to merge master to euphrates with gerrit Hi, Alec See my additional comments. On Thu, Oct 19, 2017 at 10:06 PM Alec Hothan (ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>> wrote: Hi Yujun, The stable branch is created a few weeks before the release data and a lot can happen in a few weeks. It could be lots of small commits related to docs, lots of trivial fixes. The point I wanted to make is that you do not want to see all these small detail commits on your release branch and hence the notion of having a “clean” release branch devoid of detailed small commits that do not need to be tracked at that level of branch. Say you have 20 commits to fix docs or 20 trivial fixes in code in the week before release, will you want to have 20 commits on stable branch or one? One by one, since this is the history of amending the stable branch, we should keep it as it is. If we don't want to see trivial fixes, the right way could be squash them BEFORE submitting to master branch. This is a case where a merge makes sense rather than cherry picking each of them. Normally, when we created stable branch, the master branch is mainly used for new feature development of next release. It may not be a good idea to merge them to stable branch. That's why we use cherry-pick to select only the bug fix and document amending. And this can not be done with merge. Another case where merges make sense is when you deliver 5.1.0 with possibly lots of new enhancements to 5.0, it makes sense to merge rather than cherry pick lots of commits. This also confuses me a lot, since the release date for 5.1.0 and 5.2.0 is overlapped with 6.0.0 development cycle. Normally I would add NOTHING new in 5.1.0 or 5.2.0 except for bug fixes. All new features goes into 6.0.0. This may save you from cherry-picking a bundle of commits and separate feature development from bug fixing. My another 2 cents. -- Yujun Zhang
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
