Hey, in-line;
On 18-Aug-2014, at 11:09 pm, Min Chen <min.c...@citrix.com> wrote: > Rohit, > I read your proposal, but maybe I mistook your idea: > > "- 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”. So, the next point to the above in the proposal tell you how we should do it: “”” - 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. “”” > What do you mean by this? So after release branch is cut, and contributors > need to fix a bug (as we experienced so many times in past releases), what > should they do? Based on your sentence above, I understood that they can > just directly commit to release branch instead of currently checking into > some forward branch and RM then cherry-pick it up to release branch to > control quality. What is your new proposed approach then? Please clarify. Sorry if that confused you, this is what a contributor should do: (everything in parenthesis below is just a guideline or recommendation but not a rule) 1. They should create a branch check’d out from release branch to fix an issue for the release branch and push with a bugfix or hotfix prefix (possibly with a JIRA bug ID in the branch name) and then ask RM to pick it up. In case the contributor is not a committer they can contribute their work to be applied on release branch via reviewboard. 2. Once their hotfix/bugfix branch is merged (-ff preferably to avoid having a merge commit) by the RM or the contributor is asked to rework their fix and resubmit 3. Once contributor’s work lands/merges on release branch, this branch is merged by either any committer or the RM to master (perhaps several times a day using —fast-forward to avoid merge commits). This way changes land to master as well. For supporting multiple release branches, for example fixing a bug on multiple branches such as on 4.2, 4.3, 4.4 branches, the contributor starts with 4.2 and follows the above and go on until 4.4 and finally their fix lands on master. For the long run, if we use the above if a bugfix is accepted and applied on 4.2, we could have merged 4.2 fast-forward to 4.3 branch, and then 4.3 on 4.4 and 4.4 on master. This operation will be valid and won’t cause any conflicts etc because if we take an example -- the 4.3 branch contains the whole history of 4.2 (think them as link lists) so merge -ff will result in landing the original bugfix to the next branch. This is the flow of change we could benefit from and it’s a guideline and not a rule and one will be still free to cherry-pick or fixing something manually per release branch. With our (already) releases we don’t backport or fix bugs, I hope such a workflow can be helpful for doing a LTS or long term maintenance release. The proposal also consists of scope of non-strictness and changeability, quoting: “”” - 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 “”" Cheers. > > Thanks > -min > > On 8/18/14 12:06 PM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: > >> Min, >> >> On 18-Aug-2014, at 8:25 pm, Min Chen <min.c...@citrix.com> wrote: >> >>> Rohit, >>> >>> I think that Edison and I have clearly indicated our objection reason in >>> our previous email. Based on current cloudstack quality, RM needs to >>> have >>> control over what commits to be in release branch to get a release at >>> least having some quality. With this proposed model, how can you >>> guarantee >>> the quality of a release? We cannot just talk about changing a process >>> without resolving this important concern. What is your solution to this >>> concern? >> >> In my proposal we’re not saying people “can" commit directly to release >> branches, I suggest you re-read the proposal. I cannot emphasis this >> enough that this does not try to solve the issue you’re raising (which >> deserves a thread of its own), so the expectation from everyone is to >> stick to the agenda and comment on it. >> >> Min, I’ve said this at least four times now I feel like people are just >> skimming emails :P If they are, may I deserve their attention to read my >> email with full attention like I do when I read theirs? >> >> We’re not giving power to everyone commit directly on release branches, >> so we’re not changing the status quo around this issue so there is no >> point of questioning “release quality”. >> >> This sort of workflow is something used at several companies such as >> Google and Facebook which has turned out to work for them. >> >> If you find any issues or challenges with this I would love to hear from >> you. At the end of the day as an individual wearing your Apache hat it’s >> your call and right to votes and opinions so we respect your votes but it >> would be only encouraging if they are backed by a good reason. >> >> Lastly, I don’t have the “unicorn" solution that will guarantee quality >> of a release and I think perhaps it does not exist. >> >> This proposal does not aim to solve the “release quality issue” but to: >> >> - encourage involvement of contributors during release: My personal >> opinion is that we’ve a major problem that unless a commercial >> distribution’s releases is based on ACS release, many of the “sponsored” >> developers won’t participate much in opensource ACS releasess. How do we >> solve it? I guess we need some way to increase participation, by >> increasing participation we’ll have much better release quality than >> perhaps that will less involvement. >> - a guideline to reduce conflicts and make sure no commit is missed or >> misplaced >> - give a flow of change (baseline protocol) on how to maintain multiple >> release branches >> >> Min and others, I would welcome if you’ve any issues or challenges you >> can find with “what” the above will try to implement. >> >> Cheers. >> >> >>> >>> Thanks >>> -min >>> >>> >>> On 8/18/14 10:59 AM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >>> >>>> Hi, >>>> >>>> @Jessica ‹ Can you please suggest what¹s wrong with the ³things² that >>>> were proposed here as I could not figure out your or Min¹s or Edison's >>>> individual opinion and reason behind the vote. >>>> >>>> We have three -1s (1 binding) but none of them share valid reasons or >>>> concerns that would point out issues and challenges with adopting the >>>> proposed items so we¹ll continue with the voting. >>>> >>>> Min, Jessica, Edison ‹ I would love to know what¹s wrong in the >>>> "proposed >>>> things" so we don¹t make mistake. >>>> >>>> @Rajani ‹ Thanks, but when we should cut a release branch is a >>>> different >>>> topic and IMO is per the RM¹s discretion so if you¹ve any ideas or >>>> proposals please go ahead and start a thread on that. >>>> >>>> Cheers. >>>> >>>> On 18-Aug-2014, at 6:52 pm, Jessica Wang <jessica.w...@citrix.com> >>>> wrote: >>>> >>>>> 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. >>>> >>>> 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. > 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.
