>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. I agree to this. 1) If we are introducing the 'develop' branch, it intuitively seems that it should act as a staging branch where we have some quality control before things move to master. 2) Plus as discussed in the thread, the git workflow is not solving the CS maintenance release process. So we need to have some tweaks there to support the non-rolling release model of CS. The reservation is not due to mere a 'naming' change -it's because apart from the naming change, we are still facing issues. The proposal needs to address the above, if we are planning to introduce a change, why not solve our quality/test problems with it. Thanks, Prachi 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. >> >> >> >> > >
