This sounds like an end goal that we shouldn't try to reach in one go. Let's take baby steps.
On Fri, Aug 8, 2014 at 1:28 PM, 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. -- Daan
