cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@shapeblue.com>
Subject Re: [VOTE] git workflow
Date Fri, 08 Aug 2014 11:28:50 GMT
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.hoogland@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.yadav@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.tutkowski@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.Prokharchyk@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" <runseb@gmail.com> wrote:
>>>>
>>>>>
>>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>>>> <Alena.Prokharchyk@citrix.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <runseb@gmail.com>
wrote:
>>>>>>
>>>>>>>
>>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <david@gnsa.us>
wrote:
>>>>>>>
>>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <runseb@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <david@gnsa.us>
wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>>>>>> <Alena.Prokharchyk@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.tutkowski@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.yadav@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.yadav@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.

Mime
View raw message