cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [VOTE] git workflow
Date Fri, 08 Aug 2014 07:19:59 GMT
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; (my new proposal
uses this idea) (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 <> 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 <
>> 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" <> wrote:
>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
>>> <> wrote:
>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <> wrote:
>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <> wrote:
>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <>
>>>>>> wrote:
>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <>
>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
>>>>>>>> <> 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
>>>>>> 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
>>>>>> 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:
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <>*™*

Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 |
Blog: | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<>
CSForge – rapid IaaS deployment framework<>
CloudStack Consulting<>
CloudStack Infrastructure Support<>
CloudStack Bootcamp Training Courses<>

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.

View raw message