Done, updated the wiki page with my comments. Copy/pasting here: Open items: 1) Which bugs can be submitted to develop branch directly. Document http://nvie.com/posts/a-successful-git-branching-model/ mentions that the *hotfix branch should be created for the blocker/critical bugs in the current production release. What about bugs happenning in the *release(the one that hasn't been released yet)/*develop branches ? Should we fix them directly in those branches, or should we branch out off the *release branch, fix the problem, and merge the fix to *release? We should decide: for which bugs the hot fix branch should be cut, and which fixes can go directly to *develop/*release branches. This criteria has to be defined in the doc, and be based on the a) bug severity b) number of people who work on the bug - if more than one, then we cut the new branch c) feedback/review is needed for the bug d) anything else?
2) I don't agree with the model when the person has to merge his branch/commit the fix to both develop/master branches. So there are 2 approaches that can be taken: * Currently proposed approach: ask a person always put 2 fixes - one in master and one in develop * Approach I suggest, and its used in the field a lot: Person commits the fixes to *develop branch, and then there is some job doing automatic merge from *develop to *master branch after CI on *develop passes From the past experience, I see that the first (currently proposed) approach is less desirable as a) sometimes people forget to push changes into master branch, and then the release manager has to run the merge to find those missing pieces b) IMPORTANT: it would require to run CI on both *develop and *master branch with higher frequency, plus the rollbacks in case of failure need to be done both in develop and master branches. I would advocate for the following flow: * submit fixes/merges from release/hotfix branches to *develop branch only * Run daily(?) CI on develop branch, and do merge delta to master branch only when CI passes -Alena. On 7/31/14, 1:40 PM, "Sebastien Goasguen" <run...@gmail.com> wrote: > >On Jul 31, 2014, at 4:33 PM, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: > >> +1 on the proposal. But I second Rohit and Sheng Yang - we should agree >>on >> all the flow points before we adopt it for CloudStack. We can¹t just >> blindly follow http://nvie.com/posts/a-successful-git-branching-model/, >> plus some use cases are not explained there as I¹ve pointed in one of my >> previous emails. >> > >Can you add to the wiki page then ? describe the use case that you have >in mind and explain how to address it. > >If we all collaboratively edit that page we should be able to get to a >consensus and have something that addresses all our current concerns. > > >> -Alena. >> >> On 7/31/14, 4:19 AM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >> >>> +1 >>> >>> Hugo, I think we started this voting thread to get opinion on the >>> proposal. I feel it may need some iteration and community agreement >>> before we adopt it. >>> >>> Suggestions, flames and opinions are welcome. >>> >>> Regards. >>> >>> >>> On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <h...@trippaers.nl> wrote: >>> >>>> Rajani, >>>> >>>> To make it clear for everyone. This is the vote to adopt this new way >>>> of working right? Or is it just to get an opinion on the proposal? >>>> >>>> If it is indeed the vote to adopt this way of working it means that >>>>all >>>> committers will change how we interact with the branches in the >>>> CloudStack git. >>>> >>>> It¹s is a good thing in my book, but we need to be clear what the >>>> expected result is when this vote has concluded in 72 hours. >>>> >>>> Cheers, >>>> >>>> Hugo >>>> >>>> >>>> On 31 jul. 2014, at 12:28, Rajani Karuturi >>>><rajani.karut...@citrix.com> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> We had long discussions on the git flow. >>>>> I tried to capture the summary of it @ >>>>> http://markmail.org/message/j5z7dxjcqxfkfhpj >>>>> This is updated on wiki @ >>>>> >>>>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Propose >>>>>dG >>>>> itflowbasedCheck-inProcess and is up for a vote: >>>>> >>>>> Can you share your opinion on the proposal? >>>>> >>>>> [ ] +1 approve >>>>> [ ] +0 no opinion >>>>> [ ] -1 disapprove (and reason why) >>>>> >>>>> >>>>> Thanks, >>>>> ~Rajani >>>>> >>>>> >>>>> >>>> >>> >>> 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. >> >
