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 19:59:12 GMT

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 merging
>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 is
>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 / test
>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 it.
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 of
handling maintenance releases for multiple versions of CS - see another

Instead, master branch should reflect the latest code that passed the CI
test (the code merged from *develop after CI passes). The release branches
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