-----Original Message----- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: Wednesday, August 06, 2014 3:23 PM To: dev@cloudstack.apache.org Cc: Edison Su Subject: Re: [VOTE] git workflow
On Aug 6, 2014, at 6:13 PM, Prachi Damle <prachi.da...@citrix.com> wrote: > >> 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. Can you list them specifically, one by one ? That's what is listed above #1 and #2 - We are introducing 'develop' without any quality benefit and we will possibly break the maintenance release CS model. > The proposal needs to address the above, if we are planning to introduce a > change, why not solve our quality/test problems with it. > Let's assume we have a CI/BVT infra available in apache and that every branch/commit can go through it. What would be your ideal git workflow to have: -stable master (meaning that you checkout master and you have the latest shippable product) -always release on-time. -always know where a fix should be applied (and if it has been applied everywhere) (those are my top three, we may want to add others) > 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. >>> >>> >>> >>>> >> >
