Rohit, Thank you to bring this to a end.
Finally handling multiple maintenance release is recognized as an issue in this model. --Sheng On Fri, Aug 8, 2014 at 4:28 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi, > > Vincent (nvie) has allowed me to share his email publicly, here you go: > > " > Hi Rohit, > > Thanks for reaching out. I don't think git-flow suits your use case very > well. Git flow was mainly optimized as a set of rules to help bring forth > "forward-only" releases, and does not support multiple concurrent and > non-chronological releases very well. The main reason is that getting all > the details down leads to much complexity. Back when the git-flow model was > devised it was meant to be a rule set that could be automated, and aimed at > a single release stream. Adding multiple concurrent releases would > significantly complicate the model. > > I have no advice on what model would work better for you. Of course you > could make a variant of git-flow that works with multiple "master" > branches, one for each release, but the exact semantics of which of those > to merge hot fixes in, for example, are not documented somewhere formally. > > Cheers, > Vincent > “ > > On 08-Aug-2014, at 9:23 am, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > > Rohit, this is not a git-flow or gitflow discussion. It seems to be at > > times but it is not. It is a discussion about how to branch in our > > repository. That discussion should not end, but maybe so in this > > thread. > > > > On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > >> Hi all, > >> > >> Let’s end this discussion thread. > >> > >> I asked Vincent (nvie) and some friends from google and facebook on > this and all of them recommended that this is not for us; then I read the > whole thread again without prejudice or ego and I think it’s not for us > though we should pick up couple of good ideas from it: > >> > >> - git-flow was designed for only “forward” releases > >> - git-flow does not support multiple concurrent and non-chronological > releases/support very well (no nvie documentation on how to do that) > >> > >> Instead, if you’re interested on such topic I started a proposal > (inspired by couple of workflows) on solving cherry-picking issue by > adapting our release/master workflow please have a look on that. Some good > reads on other git workflows we can get ideas from; > >> > >> > http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows > (my new proposal uses this idea) > >> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html > (read this at least once) > >> > >> PS. Let me know privately if you want me to forward you Vincent’s email > >> > >> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> > >>> This is what I was wondering about, as well. It seems all of our > 'master' > >>> problems become 'develop' problems. > >>> > >>> I do like the idea of merging versus cherry picking (as a general > rule), > >>> though. > >>> > >>> > >>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk < > >>> alena.prokharc...@citrix.com> wrote: > >>> > >>>> Sebastian, addressing the following comment of yours > >>>> > >>>> > >>>> "The main issue with master right now is that it moves really fast as > a > >>>> shared branch, people merge features without warning, we see > regressions > >>>> etc.. > >>>> By the time we release a major version, master has moved so much that > it > >>>> feels like starting over with the next release. It's almost as if we > are > >>>> forking our own software. CI alone (even if it were really good) will > not > >>>> fix this.” > >>>> > >>>> > >>>> You will still have this problem. You cut the next release branch > from the > >>>> *develop branch, not from master. And the *develop branch will move > with > >>>> the same pace as the old master, after the release branch is cut. So > >>>> “master moving really fast” problem would become “develop moving > really > >>>> fast”. > >>>> > >>>> The problems you’ve mentioned - people merge features without > warning, we > >>>> see regressions - can be fixed only with automation in place and the > >>>> requirement to run this automation (CI/BVT) before the merge is done. > >>>> Otherwise you are just shifting all existing problems from master to > >>>> develop. > >>>> > >>>> > >>>> -Alena. > >>>> > >>>> > >>>> > >>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <run...@gmail.com> wrote: > >>>> > >>>>> > >>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk > >>>>> <alena.prokharc...@citrix.com> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <run...@gmail.com> wrote: > >>>>>> > >>>>>>> > >>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <da...@gnsa.us> wrote: > >>>>>>> > >>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen < > run...@gmail.com> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <da...@gnsa.us> wrote: > >>>>>>>>> > >>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk > >>>>>>>>>> <alena.prokharc...@citrix.com> wrote: > >>>>>>>>>>> Edison, thank you for raising the concern about the BVT/CI. > >>>>>>>>>>> Somebody > >>>>>>>>>>> mentioned earlier that we should separate git workflow > >>>>>>>>>>> implementation from > >>>>>>>>>>> the CI effort, but I do think we have to do in in conjunction. > >>>>>>>>>>> Otherwise > >>>>>>>>>>> what is the point in introducing staging/develop branch? If > there > >>>>>>>>>>> is > >>>>>>>>>>> no > >>>>>>>>>>> daily automation run verifying all the code merged from > >>>>>>>>>>> hotFixes/feature > >>>>>>>>>>> branches (and possibly reverting wrong checkins), we can as > well > >>>>>>>>>>> merge the > >>>>>>>>>>> code directly to master. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Yes! - please. > >>>>>>>>>> Doing this without CI as a gating factor buys us very little. > >>>>>>>>>> > >>>>>>>>>> --David > >>>>>>>>> > >>>>>>>>> David, can you clarify. Are you going to be against any change > of git > >>>>>>>>> workflow until we get CI/BVT in place ? > >>>>>>>>> > >>>>>>>> > >>>>>>>> No, please don't take it that way. > >>>>>>>> I understand Leo's point about Cherry-picking being for fruit, > and not > >>>>>>>> code. But, I don't think that the workflow changes I've seen > proposed > >>>>>>>> affect quality. So shifting for quality's sake doesn't make a lot > of > >>>>>>>> sense in my mind. They could be a component of fixing the quality > >>>>>>>> problem. > >>>>>>>> > >>>>>>>> --David > >>>>>>> > >>>>>>> Agreed, the changes don't affect quality but should support a CI > infra > >>>>>>> that helps improves quality. > >>>>>>> > >>>>>>> I do think the changes provide > >>>>>>> > >>>>>>> -a stable master that represent released software > >>>>>> > >>>>>> > >>>>>> You can always look at the latest release branch to get it, > >>>>> > >>>>> Yes I know how to get to the latest released software. > >>>>> > >>>>> I actually don't have good answers for your questions but I think > Nate's > >>>>> email (couple emails back) answers a lot of them. > >>>>> > >>>>>> as we are > >>>>>> planning to keep them around to support maintenance. From the > developer > >>>>>> stand point, I would be more interested in getting the latest stable > >>>>>> code, > >>>>>> not the latest stable release. > >>>>> > >>>>> I think that's fine from a developer standpoint. I tend to look at > things > >>>>> from a user standpoint. > >>>>> I think a basic user who wants to check out source (because he > builds his > >>>>> own packages), would like to checkout the latest master to get the > latest > >>>>> released software (not everybody software projects works like this of > >>>>> course). > >>>>> > >>>>> The main issue with master right now is that it moves really fast as > a > >>>>> shared branch, people merge features without warning, we see > regressions > >>>>> etc.. > >>>>> By the time we release a major version, master has moved so much > that it > >>>>> feels like starting over with the next release. It's almost as if we > are > >>>>> forking our own software. CI alone (even if it were really good) > will not > >>>>> fix this. > >>>>> > >>>>> So assuming we have CI in place, we do need a better workflow (let's > not > >>>>> call it gitflow anymore) to self-discipline ourselves. > >>>>> > >>>>>> > >>>>>> I don¹t see the use of stable master branch during the release > either, > >>>>>> as > >>>>>> it reflects already released versions of the CS. And you never cut > the > >>>>>> release from the stable master branch; you do cut it from *develop - > >>>>>> that¹s what the git workflow suggests. > >>>>> > >>>>> That's where our use case differs from gitflow. Several folks have > >>>>> already mentioned that we are going to deviate from pure gitflow, it > is > >>>>> just a nice framework to start creating our own workflow. > >>>>> > >>>>> Personally, I would love to cut the release branches from master > (instead > >>>>> of develop). that way you always start from a clean slate, instead > of the > >>>>> mess with start with right now. > >>>>> > >>>>> Say develop is more of a staging branch, as you have advocated. We > can > >>>>> run CI/BVT on that branch (we should run it everywhere…but anyway) > and > >>>>> make sure features merged in work as advertized. > >>>>> > >>>>> When time comes to release, we cut from master and merge the features > >>>>> that have been merged in develop already, then go into QA, merge the > >>>>> fixes back to develop etc….when released, we merge back to master. > >>>>> > >>>>> If/since we don't do rolling releases, we branch out from the main > >>>>> version tag and do a maintenance release that leaves on, assuming it > >>>>> can't get merged back into master. > >>>>> > >>>>>> > >>>>>>> -a clean way to merge features and bug fixes > >>>>>> > >>>>>> +1 > >>>>>> > >>>>>>> -a clean way to create a release that should reduce our time to > release > >>>>>> > >>>>>> +1 Although I still think that slowness for our release was mostly > >>>>>> caused > >>>>>> by the last minute regression bugs caused by missing quality > control + > >>>>>> lack of CI. > >>>>> > >>>>> True, but it is also due to the fact that we start a release branch > from > >>>>> a messy master where regressions happen. > >>>>> > >>>>>> This new way would just take off the load from RM by > >>>>>> eliminating endless cherry-picking. > >>>>>> > >>>>> > >>>>> I would love to have a workflow where the RM has a very clean job > (pick > >>>>> the features that should be in the release, pick the hot fixes > release). > >>>>> It should just be a series of git merge and that's it. > >>>>> > >>>>> master branch is only released software, only touched by RMs > >>>>> > >>>>> released branches only touched by RMs > >>>>> > >>>>> develop shared but merges happen only after successful CI and > guarantee > >>>>> of no regressions. > >>>>> > >>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> *Mike Tutkowski* > >>> *Senior CloudStack Developer, SolidFire Inc.* > >>> e: mike.tutkow...@solidfire.com > >>> o: 303.746.7302 > >>> Advancing the way the world uses the cloud > >>> <http://solidfire.com/solution/overview/?video=play>*™* > >> > >> 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. > > > > > > > > -- > > Daan > > 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. >
