cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 19:59:12 GMT


On 8/6/14, 12:52 PM, "Erik Weber" <terbolous@gmail.com> wrote:

>On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> 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
>>the
>> 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
>was
>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.
>
>-- 
>Erik

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
thread.

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.



>


Mime
View raw message