I'm not sure what to think about this discussion any more. But in response to Sebastien's request for thoughts I was originally very excited about a git-flow solution because of some very specific things:
* Create a branch for everything. This is amazingly useful for a number of reasons: ** It supports better CI in the future, specifically build per branch. Committing directly to a shared branch with CI is not the same thing. I see great utility in running CI *twice* for every change coming in. Once in isolation, and again once it is merged in with the rest of the community work. This enables you to validate that your code is good before subjecting others to it, and isolates regression testing to just that. It gets much more difficult to determine if the problem is basic logic in your code or a regression somewhere else when you don't isolate the changes. ** It encourages people to not force others to deal with something that isn't completely done or tested, but allows them to still have frequent commits and share through the central repo. Any time you modify a shared branch you should be extremely confident that what you have done will only be a positive impact on the others using that branch. If something breaks, you are potentially disrupting the work of a large number of other people in the process. Internally we follow a strict branch and peer review process for every change. As much as I would like to propose a strict peer review process for all changes, I have a feeling that it would get even more pushback than this proposal. I also want to highlight the force part of my statement. If your change breaks something unrelated to my code, and now I have to go fix that so that I can get back to what I was originally doing, I have no choice but to deal with that breakage and am probably very angry because of that. * The release process happens in parallel to active development. By using a release branch to work through QA, testing, bugfixes you enable that work to happen independent of anything else happening in the code base. I realize that we already have this process in place for the most part, I just wanted to highlight that it is something we are already doing in some form and get to keep doing. * A stable branch is maintained that only contains code that has been through a release process. I understand the desire for a nightly process that merges code from dev to stable, but what is this solving that CI on all of the branches wouldn't solve? It also assumes that the CI process is perfect and that all new code has extensive unit/integration tests. Both of these should be true, but rarely are in the real world and are nowhere close in today's ACS environment and will take a long time to fix. I also don't see the momentum to accomplish this in the very near term, so it feels a bit like we are betting on the the weather a month from now to save us. I also realize that git-flow isn't a perfect match for how this community works, but rolling releases versus maintenance releases doesn't seem major enough to drop the entire thing. It is fairly easy to have a maintenance/support branch for older releases that lives on forever once it is needed. You can also merge any two arbitrary items in git. It might not be the cleanest merge, but you can merge the maintenance branch into master once the release of the maintenance branch is done. You could treat it much like a new release or development branch that comes from master instead of develop. If this didn't work, long running branches would never work in git. The TLDR proposal: * Always make a branch for everything * Have a branch that is only released code. Not just stable and CI tested, released. * Have a development branch where features that haven't been through a release process can branch from and land when complete * Use a release branch to move all changes from development to stable to isolate testing, QA, and release bugfixes * Create a maintenance branch from the release tag in master once a maintenance release is needed I don't care if we call it git-flow, I just liked that it provided a basic framework from which we could operate and extend. Thanks, -Nate On Thu, Aug 7, 2014 at 8:39 AM, Tracy Phillips <tracp...@weberize.com> wrote: > 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. > > >>>> > > >>>> > > >>>> > > >>>>> > > >>> > > >> > > > > > > > > -- *Nate Gordon*Director of Technology | Appcore - the business of cloud computing® Office +1.800.735.7104 | Direct +1.515.612.7787 nate.gor...@appcore.com | www.appcore.com ---------------------------------------------------------------------- The information in this message is intended for the named recipients only. It may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this message is strictly prohibited. If you have received this e-mail in error, do not print it or disseminate it or its contents. In such event, please notify the sender by return e-mail and delete the e-mail file immediately thereafter. Thank you.
