cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <>
Subject Re: [DISCUSS] git commit proces
Date Mon, 28 Jul 2014 16:15:47 GMT

This thread summarizes gitflow and the git process talk Rajani shared
with us in the other thread:

This is what Rajani shared during the end of the thread:

After reading 58 emails on the original thread, here what I've to
suggest and discuss:

- adapt the "gitflow" to our workflow, we don't need to enforce it or
its esoteric concepts
- have a stable master because everyone ends up using master including
the new contributors

Feature development and bug fixes:
- work on a branch checked out from master or release branches
- don't commit on master by default, only if you're sure and have passed
by success builds and tests

Backporting changes: (from one branch to other branch/release)
- don't cherry pick if there are too many commits (say 50+) instead I
recommend using branching & merging
- in case of feature work/refactoring and work that results in a lot of
conflict, use squash merging that results in few revert-able commits

Open ended questions:
- How do we have a workflow that supports backporting changes/features
to old releases say 4.0, 4.1 etc.
- How do we insure this is well communicated to everyone and everyone
follows what we'll agree by vote or scout's honor
- For merging any feature work or branch or cherry-picking commits to
master do we need to have a review requirement using reviewboard etc?


Daan Hoogland wrote:
> Let me explain a little more about this lat mail of mine.
> I was assuming a lot of context that most people may not have.
> We want to start working differently with respect to our release
> procedure and branching habits. The proposals that are out there and
> about to be voted for are going to require a lot of work of a few
> people and a lot of discipline from all of us.
> My idea was to first vote for some of the habits that are part of the
> gitflow discipline, but I am not strong opinionated about that.
> I do want to prevent that we go for a grand proposal to completely
> change our way of moving forward (not just the way we move forward)
> while there are potentially people opposing to this way of working.
> So please give a +1/0/-1 to the general idea now, so we fell
> comfortable spending the time in devising a new release
> schedule/mechanism.
> some of the highlights are:
> it will start with 4.5 (4.4.x will be done with the old manual
> cherry-pick process)
> it will require everybody to create a branch for every fix or feature
> they will contribute.
> it will require devs to work mainly on a new branch call 'develop'
> it will be every bodies responsibility to ensure that 'master' is at
> all times releasable
> thanks,
> Daan
> On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland<>  wrote:
>> I am not for a grand proposal but ok, I can live with it.
>> It would be easiest to just vote for using the gitflow model.
>> Leo is preparing a page on how to do it. I don't know what the status
>> is on it. The vote for my part would be on the contents of that page.
>> On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski
>> <>  wrote:
>>> Yeah, I was under the impression this decision would require a vote and
>>> formal announcement, if it passes.
>>> On Monday, July 28, 2014, Hugo Trippaers<>  wrote:
>>>> Agreed,  this kind of important decisions should be made by a vote.
>>>> Sebastien, Daan, can one of you kick of the vote thread? Preferably with
>>>> condensed summary of the thread?
>>>> Cheers,
>>>> Hugo
>>>> On 28 jul. 2014, at 14:07, Ian Duffy<<javascript:;>>
>>>> wrote:
>>>>> +1 to what Erik said.
>>>>> On 28 July 2014 13:04, Erik Weber<<javascript:;>>
>>>> wrote:
>>>>>> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland<
>>>> <javascript:;>>
>>>>>> wrote:
>>>>>>> H,
>>>>>>> I see a lot of commits happening directly on the master branch.
>>>>>>> there were no counter arguments against the proposed gitflow
and the
>>>>>>> discussion around it. This leaves me with the idea that the thread
>>>>>>> largely ignored by the community. It is my understanding that
>>>>>>> agreed never to commit anything to master anymore that hasn't
>>>>>>> first committed to a branch and is merged back to master (instead
>>>>>>> cherry-picked). What mistake in thinking am I making here?
>>>>>> Not familiar with bylaws and the such, but wouldn't a change like
>>>>>> require some sort of voting and potentially a more formal information?
>>>>>> Requiring everyone to read through a 50+ replies mail thread and
>>>> comprehend
>>>>>> it could be a bit much.
>>>>>> I would suggest an updated document that explain the expected workflow.
>>>>>> --
>>>>>> Erik
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e:
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <>*™*
>> --
>> Daan

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