> -----Original Message----- > From: Alena Prokharchyk [mailto:alena.prokharc...@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" <terbol...@gmail.com> wrote: > > >On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk < > >alena.prokharc...@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. > > > > >
