Any other suggestions/objections/comments?? Can we discuss this in detail and agree to a process??
~Rajani On 02-Jun-2014, at 9:32 am, Rajani Karuturi <rajani.karut...@citrix.com> wrote: > Yes as mike said, if its a one-off case we can do a empty merge(merge -s > ours) for it and git will assume its merged but will not bring in any changes. > > If the branches diverged a lot, for example after a major rewrite, we could > stop merging to that branch and above and make the fix manually. > > > ~Rajani > > > > On 30-May-2014, at 11:26 pm, Mike Tutkowski <mike.tutkow...@solidfire.com> > wrote: > >> Yep, that's what I was referring to in that a particular fix for an old >> release may not apply to newer versions. That does happen. >> >> We used to mark those as "don't need to merge to branch x" in SVN and then >> you handed it however made sense on the applicable branch(es). >> >> >> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <stephen.tur...@citrix.com> >> wrote: >> >>> What happens if a fix isn't relevant for newer versions, or has to be >>> rewritten for newer versions because the code has changed? Don't the >>> branches diverge and you end up cherry-picking after that? >>> >>> -- >>> Stephen Turner >>> >>> >>> -----Original Message----- >>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >>> Sent: 30 May 2014 18:48 >>> To: dev@cloudstack.apache.org >>> Subject: Re: [PROPOSAL] git workflow >>> >>> I think this flow is something we should seriously consider. >>> >>> I find cherry picking from branch to branch to be error prone in that it's >>> easy for someone to forget to cherry pick to all applicable branches and >>> you don't have any easy way to see the cherry picks are related. >>> >>> When I worked at HP, we had automated tools check to see if you checked a >>> fix into a prior release, but not later releases. In such a situation, you >>> either 1) forgot to perform the check-in or 2) the check-in was no longer >>> applicable in the later release(s), so you needed to mark it as >>> un-necessary (SVN supported this ability...not sure about Git). >>> >>> >>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < >>> rajani.karut...@citrix.com> wrote: >>> >>>> Hi all, >>>> >>>> >>>> >>>> Our current git workflow is confusing with the *forward branches and >>>> cherry-picking. Its hard to track on what all releases the commit has >>>> gone into unless I do some git log greping. Also, as a contributor, I >>>> endup creating patches for each branch as it doesn’t cleanly apply on >>>> different branches. >>>> >>>> >>>> >>>> I think we should have some guidelines. Here is what I propose. >>>> >>>> >>>> >>>> 1. There should be branch for every major release(ex: 4.3.x, 4.4.x, >>>> 5.0.x,5.1.x) and the minor releases should be tagged accordingly on >>>> the respective branches. >>>> 2. The branch naming convention is to be followed. Many branches >>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing >>>> 3. Cherry-picking should be avoided. In git, when we cherry-pick, >>>> we have two physically distinct commits for the same change or fix and >>>> is difficult to track unless you do cherry-pick -x >>>> 4. There should always be a continous flow from release branches to >>>> master. This doesn’t mean cherry-picking. They should be merged(either >>>> ff or no-ff) which retains the commit ids and easily trackable with >>>> git branch --contains >>>> * Every bug fix should always flow from minimal release uptill >>>> master. A bug isnt fixed until the fix reaches master. >>>> * For ex. A bug 4.2.1 should be committed to >>>> 4.2.x->4.3.x->4.4.x->master >>>> * If someone forgets to do the merge, the next time a new commit >>> is >>>> done this will also get merged. >>>> 5. There should always be a continuous flow from master to feature >>>> branches. Meaning all feature branch owners should proactively take >>>> any new commits from master by doing a merge from master >>>> 6. The commits from feature branch will make to master on code >>>> complete through a merge. >>>> 7. There should never be a merge from master to release branches >>>> 8. Every commit in LTS branch(targetted to any minor release) >>>> should have atleast bug id and correct author information >>>> * Cassandra's template: patch by <author>; reviewed by <committer> >>>> for CASSANDRA-<ticket> >>>> 9. Once the release branch is created(after code freeze), any bug >>>> in jira can be marked with fix version current release(4.4) only on >>>> RM's approval and only they can go to the release branch. This can be >>>> done through jira and with certain rules.(may be using jira vote?) >>>> this would save the cherry-picking time and another branch maintenance. >>>> >>>> >>>> >>>> Please add your thoughts/suggestions/comments. >>>> >>>> >>>> >>>> Ref: >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html >>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0 >>>> >>>> ~Rajani >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the cloud >>> <http://solidfire.com/solution/overview/?video=play>*™* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* >
