Edison, thank you for raising the concern about the BVT/CI. Somebody mentioned earlier that we should separate git workflow implementation from the CI effort, but I do think we have to do in in conjunction. Otherwise what is the point in introducing staging/develop branch? If there is no daily automation run verifying all the code merged from hotFixes/feature branches (and possibly reverting wrong checkins), we can as well merge the code directly to master.
-Alena. On 8/6/14, 2:30 PM, "Edison Su" <edison...@citrix.com> wrote: > > >> -----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. >> >> >> >> > >
