cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <Rajani.Karut...@citrix.com>
Subject Re: [PROPOSAL] git workflow
Date Mon, 02 Jun 2014 04:02:45 GMT
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.tutkowski@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.Turner@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.tutkowski@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.Karuturi@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*


Mime
View raw message