On Wed, October 18, 2017 at 7:23 PM, Yujun Zhang (ZTE) wrote: > This could do the trick but I don't quite recommend it. There would be > some commits on master you do NOT want to include in stable branches. > > I suggest to pick commits carefully after inspection and do the > cherrypick one by one on gerrit. It will keep a record of which patch > sets have been cherry-picked in review history (not just git log).
Yujun, I was assuming given the context of wanting to merge, there weren't any changes in master Alec didn't want in the stable branch. And I definitely agree discretion should be used in cherry-picking changes! Alec, For reference our Stable branch guide[1] is largely based on OpenStack's [2] and OpenStack definitely has a more fleshed-out guide that's worth a read. On Thu, Oct 19, 2017 at 02:06:38PM +0000, Alec Hothan (ahothan) wrote: > 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? Absolutely 20. I'm not sure what a 'clean' git history looks like, but I definitely think being able to see which specific commits were introduced to the stable branch are important to ensure it is staying stable. Introducing merge commits actually confuses things, because you no longer have insight into which patches were added (in Gerrit, not Git) to stable after the cut over. > This is a case where a merge makes sense rather than cherry picking > each of them. One of the things a stable branch enables is for you to continue development for the next release while the current one is in the works. If you were to merge master into the stable branch at any point after your work had progressed, then you would be in a lot of trouble and have to revert commits. > The rebase/squash is OK too but as I noted you do not have the git > pointer from master to release branch commit to indicate that you > actually did a merge. Correct, though the rebase/squash was only proposed as you are trying to catch up with where the master branch is. I don't think it's a good thing to do regularly as it's completely destructive to history. Regards, Trevor Bramwell [1] https://wiki.opnfv.org/display/SWREL/stablebranch [2] https://docs.openstack.org/project-team-guide/stable-branches.html#review-guidelines
signature.asc
Description: PGP signature
_______________________________________________ opnfv-tech-discuss mailing list [email protected] https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
