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
