+1 for merges(no-ff) from stable to unstable. There are pros and cons of ff and no-ff. I prefer no-ff.
-1 on frequent merges in RC stage. IMO, we shouldn't cut a release a branch until we are reasonably sure that we have a stable branch. Which would mean everyone working on the release. once we cut the branch, we start working towards the next release and the release focus is lost. I also prefer a single merge after the release is voted. (The changes should be minimal) ~Rajani On Fri, Aug 15, 2014 at 3:55 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hello everyone, > > With reference to my proposal on changing our release-master commit flow > [1], I would like to start a voting thread to decide on the adoption > starting 4.5 release. Any opinion, ideas, modifications is welcome to help > reach a consensus and improve our present situation. > > Today’s Friday so it will be only fair to extend the voting window to more > than our usual 72 hours window. > Therefore, we’ll end this voting on Wednesday, 20 August 2014 at 18:00H > UTC giving about 5 days of time for people to share what works and what > does not. We’ll stop anytime we've three -1s (binding). > > Short summary: > > - Base line protocol: Continuous changes from release/stable branches to > master/unable branches > - Get contributors more engaged with release branches by working (fixing > bugs, docs etc.) on release branches first (and not on master) > - Fixes on release branches are recommended (non strict enforcement) go > via a hotfix/bugfix branch that get automatically tested by Jenkins, when > they are green RMs get the changes to release branch > > Long Summary of what we’ll adopt: (I’m skipping writing them on wiki, as > this may change/modify in this thread) > > - Continuous flow of changes from stable branches to un-stables ones i.e. > from release branches to master and from master to features etc. Use of > merge —fast-forward is encourages over cherry-picking and —no-ff (no ff > will create merge commit). This happens couple of times a day to ensure we > get solid/robust changes from release branches (such as bugfixes etc.) on > master, any conflicts will be resolved. If we do it continuously we’ll also > save ourselves from a big conflict at the end of the release cycle and > we’ll also avoid missing/misplacing any commit when cherry-picking. > > - After code freeze is declared and release branch is cut out, > contributors work on fixing bugs and other changes (such as documentation, > build/packaging fixes etc.) first on the release branch (and not master). > This is not to restrict anyone working on master, features and other > changes can keep landing on master as well. This is to encourage > contributors to give more attention to release branches by at least fixing > bugs on release branches first and not our current way where we fix it on > master and ask RMs to cherry pick it to release branch. > > - Changes to release branches can be done by pushing a bugfix/change > branch and asking the RM to pick it up if they are tested. Our automated > systems can perform checks on such branches too (starting with a suffix > that can automatically trigger such builds/tests) and if everything is > fine, RMs to land the changes to release branches. > > - Nothing is written in stones, this should be change-able. And, this can > only work if we all agree to follow this with 4.5 > > To make the best of this thread, please keep your reply short, > constructive and to the point.. > Please share your opinion on this proposal with suitable reasons: > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > [1] http://markmail.org/message/ucixhhdbz3ajyv2a > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > M. +41 779015219 | rohit.ya...@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > Find out more about ShapeBlue and our range of CloudStack related services > > IaaS Cloud Design & Build< > http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > CloudStack Infrastructure Support< > http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training Courses< > http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based > upon its contents, nor copy or show it to anyone. Please contact the sender > if you believe you have received this email in error. Shape Blue Ltd is a > company incorporated in England & Wales. ShapeBlue Services India LLP is a > company incorporated in India and is operated under license from Shape Blue > Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil > and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is > a company registered by The Republic of South Africa and is traded under > license from Shape Blue Ltd. ShapeBlue is a registered trademark. >
