Alena, Check this out and see if it would resolve your concern regarding maintaining multiple releases
http://stackoverflow.com/questions/16562339/git-flow-and-master-with-multiple-parallel-release-branches git-flow uses support branches to support releases that are not on master. On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote: > > > On 8/6/14, 3:18 PM, "Sebastien Goasguen" <run...@gmail.com> wrote: > > >[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). > > > Sebastian, we can’t adopt this particular high level thing - when master > reflects the latest stable release with the tags for all previous releases > - because support maintenance releases for multiple CS versions in > parallel. And while master’s latest version is 4.4, 4.2.1 and 4.3.1 can be > released. And there is no way to merge them back to master w/o breaking > the branch history. > > The model when master reflects the latest released branch, can be used for > the systems with rolling upgrades only, no maintenance releases for > previous versions of the software. > > To get more details, please read the latest email exchange (today’s) on > git workflow between me/Rohit and Dave Nalley. > > > > > > >-Release: from the time a release branch is cut, features are only merged > >by RM. 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) > > > >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. > >>>> > >>>> > >>>> > >>>>> > >>> > >> > > > >
