Daan, thank you. Please see my comments inline.
On 8/7/14, 1:19 PM, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: >> Plus if you read the discussion below the article, you will see that >> people agree that this model doesn’t work well for the case when the >> product support maintenance for older releases, like CS does. > >Not at all, Alena. I don't agree that this model won't work for CS and >I think you are over estimating the amount of people that think so. >This model does work using support branches. It will work very well in >the CS case and is not very far removed from what we are doing right >now. There will always be port work when fixes in older versions need >to be made. You don't merge back support branches to tag the >maintainance release on the master branch. The fix-release-tag can >remain on the branche whether it is merged back or not. The witch hunt >on cherry picking is only perceived. There will be occasions it is >necessary but seldom so. Does it mean that our master branch will miss the fixes from support branches? Or you say we should cherry-pick them all on the top of the master branch. Again, I don’t see how maintaining master branch to reflect the latest release branch, can stabilize our release process. You will still continue to cut the release branches from *develop, which you can’t really call “stable” with this model. I’m still convinced that the best solution in our case would be introducing: * develop branch as a staging branch * merging develop branch to master on a regular basis after the CI test passes * cut release branch from the stable master branch when its time for the release I’m really trying to find the advantages of git-flow model where master reflects the latest release branch, and can’t find any considering that in the CS we are still going to keep those release/support branches, and if people need the latest release code, they can simply get it from there. From the developer stand point, I would be more interested in getting the latest stable code, not the latest stable release. And with the model I propose, that would be the master branch you get the latest stable code from. From release management perspective, I would be more interested in cutting the release branches from the stable branch - gitflow suggests to cut it them from *develop branch rather than master - and *develop is not a stable branch. I don’t see the use of stable master branch during the release, as it reflects already released versions of the CS. May be I am missing the point. Would appreciate people explaining the purpose of a git-flow way of keeping master branch, to solve the existing CS problems. Just because “its a best practice for others” doesn’t sound very convincing. > >> >> "I think this model does not work for bugfixing in older releases, >>though. >> It messes up the neat ordering. >> >> 1. Say we have released Version 1.0.1 and later added features and >> released 1.1.0. >> 2. We discover a bug in 1.0.1 and want to fix it in both version >> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer >>(or >> before) also 1.1.1.” > >No this is not true. You can branch 1.0.1 to make 1.0.2 and merge >after it is done, > Merge on a top of 1.1.0, which is the top of master branch? >next you can branch from 1.1.0 to make 1.1.1 and >merge that. >the commits that point to 1.0.2 and 1.1.1 wil not be >removed when deleting the branches and when the fixes are the same and >the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be >branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the >one exception. you don't merge back. you keep the support branch. > >This is not to far from what we do right now except that we keep old >branches preemptively right now. > >> >> >> Thanks, >> Alena. >> >> On 8/7/14, 10:19 AM, "Alena Prokharchyk" <alena.prokharc...@citrix.com> >> wrote: >> >>>Not quite. That’s what the article suggests: >>> >>>"If you want to fix bugs for older releases or do any other develop >>>there, >>>you will fork a support branch from the appropriate commit in master >>>(you >>>will have all versions ever created there). These branches are just >>>started and not intended to be merged back to master nor develop. This >>>is >>>usually fine, as fixes to "ancient" releases or features requested by >>>customers to be implemented in "ancient" releases can't or should not go >>>back into master. If you still think, you want to port a fix to your >>>main >>>development line (represented by master and develop), just start a >>>hotfix, >>>cherry-pick your changes and finish the hotfix." >>> >>> >>>That doesn’t seem right to me - that NOT ALL the fixes done to >>>4.2.1/4.3.1 >>>maintenance releases for example, will go back to master/develop? Plus >>>it >>>suggests “cherry-picking” stuff if we decide that some fixes worth being >>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt >>>purpose. I think ALL fixes done to any forked branch, should make it >>>into >>>master via merge. >>> >>> >>>On 8/7/14, 6: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-mu >>>>lt >>>>i >>>>ple-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. >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>>> >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> >>> >> > > > >-- >Daan
