cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: [VOTE] git workflow
Date Wed, 06 Aug 2014 21:30:32 GMT


> -----Original Message-----
> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> Sent: Wednesday, August 06, 2014 12:59 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] git workflow
> 
> 
> 
> 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.

+1, we need to take action to make sure master is stable. Frankly speaking, 
I don't want to fix the regression on the master, I assume nobody want to do that.
Here is the list of regression issues(not introduced by myself) I fixed on master after 4.4:

CLOUDSTACK-7123
CLOUDSTACK-7110
CLOUDSTACK-7166
CLOUDSTACK-7164
Most of this issues will be caught even by a simulator BVT. I want to make it clear, that,
If we don't take action to reduce/eliminate the regression as much as possible in the future,
I will not fix any of this regression issues.
I remember there is discussion about setting up a staging branch, run BVT against it for each
commit, what's the conclusion if any? Why so difficult to make it happen? Is there anything
I can help to make it happen?

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


+1, I'll -1 on any of proposal, if it doesn't solve problem most of us are concerning about.

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