Sorry, ignore #2. I’ve read on the model more, and realized that master branch would reflect the branch that has been released, not the current release.
So only #1 is yet to be addressed. -alena. On 7/31/14, 2:03 PM, "Alena Prokharchyk" <alena.prokharc...@citrix.com> wrote: >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-Propos >>>>>>e >>>>>>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. >>> >> >
