cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 21:33:35 GMT
Daan, thank you for the summary. See my answers below.

On 8/6/14, 1:59 PM, "Daan Hoogland" <> wrote:

>I think this is a matter of semantics. If you call the latest version
>that got through the CI a pre-release and add them as releases in the
>git-flow way of working on master you've got what you envision.


>In spite of my mail this morning I am not a warrior (though I like the
>compliment, Rohit) of gitflow but I feel that it fits whatever we need
>so far. 

My main point of objection was the way they maintain the master branch -
to reflect the latest release, which doesn’t suit the CS maintenance
releases model. Plus we can’t remove the release branches like the
original model does.

>I have read no contradiction to that so far. The only real
>change to our present way of working , given that we will use support
>branches, is that we don't build releases on the basis of cherry-picks
>anymore, which is not a very big change. Other then that, naming is
>all that is left.

Yes, merges instead of cherry-picks and introducing a staging (*develop,
or *pre-release) branch - that was all missing in the CS before, and we
have to implement it.

>Maybe I lost view on the obstacles and objections and am being short
>sighted here, please advice,
>On Wed, Aug 6, 2014 at 9:59 PM, Alena Prokharchyk
><> wrote:
>> On 8/6/14, 12:52 PM, "Erik Weber" <> wrote:
>>>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>>>> wrote:
>>>> Agree with you, Rohit. The changes to the git model we use, are needed
>>>> indeed. But we should address only the problems that CS faces, and the
>>>> main problem - quality control. The proposal should be limited just to
>>>> changes that are really needed for the CS, and that will work with the
>>>> current CS model (minor maintenance releases support is a part of it)
>>>Theoretically you don't really have to change anything other than
>>>instead of cherry picking.
>>>That is the main issue from a release perspective.
>>>But I still think there are good reasons to do so;
>>>1) using a well known way of handling code/releases instantly tells new
>>>contributors / committers how we work. add to the fact that there exists
>>>tools to help doing this correctly is a bonus.
>>>2) having a known stable (atleast in theory) release as master is good
>>>practice. although not many users will be running from git, i still
>>>consider it to be good practice.
>>>3) there is a huge belief in this thread/discussion that as long as
>>>something passes CI / BVT it is considered stable. The fact is that it
>>>not. Take the recent 4.4 release as a good example, where a new install
>>>not working at all at the point of release. Now, this is more a CI /
>>>coverage issue than git workflow issue, but i find it weird to use as an
>>>argument for not improving the workflow.
>> I¹m not arguing against keeping master release stable; I advocate for
>> But we can¹t adopt git workflow way of keeping master branch to be a
>> reflection of the latest release branch. It will not work with our way
>> handling maintenance releases for multiple versions of CS - see another
>> thread.
>> Instead, master branch should reflect the latest code that passed the CI
>> test (the code merged from *develop after CI passes). The release
>> should be cut from stable master branch - it will ensure that we won¹t
>> face last minute blockers as for 4.4, because master IS a stable branch.
>> And yes, we should do merges instead of cherry picking.

View raw message