See my comments inline. Thanks -min
On 8/18/14 3:22 PM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >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. [Min] Thanks for clarification on this. In this case, this is required after release branch is cut. For each bug fix, contributor needs to create a personal branch and fixes there, then ask RM to manually merge branch, right? So we still need a RM to do such manual things. If so, what is the advantage of this new model compared to currently contributors committing into <release>-forward branch and then ask RM to cherry-pick? I am not against your #3 above. > >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. [Min] I don't quite understand why you are saying that it won't cause conflicts when we do 4.2 fast-forward to 4.3 branch. What if the codebase in 4.3 has been changed a lot? > >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.
