cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [VOTE] git workflow
Date Wed, 06 Aug 2014 20:59:52 GMT
Alena,

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

Maybe I lost view on the obstacles and objections and am being short
sighted here, please advice,
Daan

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



-- 
Daan

Mime
View raw message