Also a -1 on this, from all points made in previous replies. Thank you, Brian
-----Original Message----- From: Jessica Wang [mailto:jessica.w...@citrix.com] Sent: Monday, August 18, 2014 9:52 AM To: dev@cloudstack.apache.org Cc: Edison Su; Min Chen; Sheng Yang; rohit.ya...@shapeblue.com Subject: RE: [VOTE] Adapting git workflow for release branches I agree with Edison. I am -1 on this as well. -----Original Message----- From: Edison Su [mailto:edison...@citrix.com] Sent: Saturday, August 16, 2014 12:11 PM To: dev Subject: RE: [VOTE] Adapting git workflow for release branches I agree with what Min said on thread: http://markmail.org/message/dqdlqu7phgijfelc, and not satisfied with your answer: Currently we don't have a CI running continuously, no code review, it's too risky to let developer check in whatever commit they want into release branch. RM needs to have to control over what commit should be put into release branch and what should not, otherwise, we could get into a stage where no control on the quality. How RM will do the control, that's something we could discuss. I know, current model is not scale, as RM needs to manually cherry pick commits into release branch. The way I thinking about, is all the commits put into release branch, must be put into review board, or gerrit, must be passed by CI and reviewers, then the commits can be put into release branch. For above reason, I am -1(binding) on your proposal for now until we solve the quality control problem. > -----Original Message----- > From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] > Sent: Friday, August 15, 2014 3:25 AM > To: dev > Subject: [VOTE] Adapting git workflow for release branches > > 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.
