+1
On Fri, Aug 15, 2014 at 1:46 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Thanks Wido! > > Let me clarify the baseline protocol or flow of change: > When fixing a bug, you start with the oldest ACS release you want to fix > it for say 4.2 and go on with 4.3, then 4.4 etc. until you land master, > followed by feature/personal branches. When in doubt, use the flow which is > from stable/firm branches to less firm branches. > > In the above example, after you fix it on 4.2 you should use merge > -ff-only (-ff is recommended but you may also you cherry-picking or fix it > manually in case of major conflicts due to code divergence) to 4.3, 4.4, > master and so on. If you merge -ff a released branch say 4.2 to 4.3, it > should *not* cause any conflict as 4.2’s history is already with 4.3 (think > them as link lists) so it should result in one commit only (that’s the > bugfix and ideally no conflicts). > > Cheers. > > On 15-Aug-2014, at 1:30 pm, Wido den Hollander <w...@widodh.nl> wrote: > > > > > > > On 08/15/2014 12:25 PM, Rohit Yadav 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 > > > > +1 for me. > > > > The current system with the branches has frustrated me a couple of > times. This way of branching can be seen with multiple projects and seems > to be working there just fine. > > > >> [ ] +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. > > 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. > -- Daan
