There is also the problem of cherry-picking. As a contributor, I always endup creating multiple patches for each branch as they don’t cleanly apply on the upward branches. which means distinct commits for each branch and I don’t easily know which all branches my commit exists unless I do grep. if we follow merging strategy properly, apart from the first merge of the branch, everything else on top of it should be a painless merge.
~Rajani On 02-Jun-2014, at 10:51 pm, Marcus <shadow...@gmail.com> wrote: > I think many of the bullet points are what we are currently doing > (guidelines for commit comments, feature branches need to stay in sync with > master, no back-merging). I also think that much of what we do now is done > the way it is simply because there *are* vast changes between versions. > Classes are getting shuffled around and changed all the time. If its > feasible to merge branch fixes to master, that's fine, but some quick tests > seem to indicate that this will be messy getting started. > > That leaves us with how we do releases. I'm fine with having single > branches for major releases(4.3) and tagging the commits where each > incremental release (4.3.x) is done. I'm trying to remember why we went > with the -forward, I'm sure it's in the mailing list somewhere, but one of > the nice things it provides is the ability for the release manager to > control what changes are made during code freeze while giving people a > place to stage fixes (though admittedly this is not always followed). > Without -forward, would the flow be for each dev to have their own repo and > issue pull requests for bugfixes? > > > On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <rajani.karut...@citrix.com> > wrote: > >> 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>*™* >>> >> >>
