> -----Original Message----- > From: Sebastien Goasguen [mailto:run...@gmail.com] > Sent: Wednesday, August 06, 2014 3:19 PM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] git workflow > > [top posting, apologies in advance] > > I am on vacation, so I will go straight to it :) > > This all discussion is not about gitflow specifically, it is about modifying > our > git workflow and our commit practices to something more standard that > can: > > - ultimately help improve quality (in itself it won't but it can help lay a > foundation) > - provide a stable master (it keeps breaking, it has regressions, it moves > really fast etc..) > - help cut releases > > Any committer has write privileges and can do whatever it wants to the > repos, so we need to get a nice big consensus on what problems we are > trying to solve, and how best to get there. So let's not make this a debate of > yeah or neah gitflow. > > A better CI is coming but it's not yet there and we have no ETA. Even with a > CI infra in place, we will need commit discipline to improve quality > (covertity, unitests, simulator tests). Changing our git commit practices has > no cost (just emails and self discipline), so can we agree to do that first ? > > Here are couple high level things that I have in mind ( and I confess I have > not read the entire threads on this yet and ti ma conflict with gitflow). > > -Master: what goes in master is only something that has been put into a > release (aside from the maintenance releases fixes maybe...). Master is the > base for any release branch (until we get to 4.5, master will still see some > high churn to stabilize it, after 4.5 release branch is cut we should enter > into > a stable master mode). > > -Release: from the time a release branch is cut, features are only merged by > RM. [Animesh] Features have to be merged into develop branch before the feature freeze date in order to make into release branch. This is not done by RM but the feature developer. Release branch should already have features that made it by the feature freeze date
hot fixes are only merged by RM. the RM is responsible for the entire > release process. Since he defines the scope and is the primary person > responsible to check BVT for the release branch he should be able to release > on-time. Major release gets merged back into master. > > -Devs: folks working on features and fixes are responsible to merge into the > develop branch and call the RM for a merge into a release branch (this may > vary with gitflow, where release branch is cut from develop) [Animesh] I want to be clear on timing for this otherwise RM cannot scale and will drown in these requests. When Chip and I were running releases we started cherry-picks when we got closer to RC. I did not see cherry-pick as a big pain for 4.2 and 4.3. > > Once we have CI, it should run on every branch. > > -sebastien > > > On Aug 6, 2014, at 5:36 PM, Alena Prokharchyk > <alena.prokharc...@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. > > > > 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. > >>> > >>> > >>> > >>>> > >> > >
