cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <LSim...@schubergphilis.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Wed, 23 Jul 2014 10:16:51 GMT
Hey folks,

With 4.4.0 tagged, is now an opportune time to go and implement this?

I would enthousiastically +1 and get crackin', but I’m not a committer so its not that practical
for me to volunteer!

I wanted to point out atlassian’s description of gitflow

  https://www.atlassian.com/git/workflows#!workflow-gitflow

which might be easier to read.

Similarly, the git-flow scripts that help out with implementing this stuff

  https://github.com/nvie/gitflow

they also describe the relationship between gitflow and dealing with multiple remotes

  https://www.atlassian.com/git/workflows#!pull-request

Finally note atlassian’s free sourcetree GUI has built-in support for git-flow

  http://www.sourcetreeapp.com/

Because cloudstack currently is full of rebasing and squashing and cherry-picking, you get
very little benefit from a tree visualization tool (like this or gitk or ...) right now, but
it would be *great* to have going forward.


cheers,


Leo

On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <runseb@gmail.com> wrote:

> I would like to re-start this discussion.
> 
> Rajani made some good points and someone mentioned Gitflow:
> 
> http://nvie.com/posts/a-successful-git-branching-model/
> 
> Thinking about our release procedure, we clearly need more tests and a CI. However it
looks like this is going to take some time.
> 
> In the meantime I think there is nothing preventing us from agreeing to 'git practices',
we don't need tests or new infra, we just need to agree on the git workflow.
> 
> Right now Master is really a development branch, we should make it a stable branch for
production with very few commits.
> This does not mean that we would release less, in contrary this would ensure that a commit
to master means it's a production release.
> 
> In addition gitflow [1] does not do cherry-picks (gets back to Rajani's point) everything
is based on merges.
> 
> I am of the opinion that git flow provides a nice process. It basically freezes master.
Development happens in a 'develop' branch, releases branches are branched off of that and
merged into master and back into develop….etc
> 
> Please read [1] it's a good read.
> 
> And let's discuss,
> 
> [1] http://nvie.com/posts/a-successful-git-branching-model/
> 
> -Sebastien
> 
> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <Rajani.Karuturi@citrix.com> wrote:
> 
>> 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 <shadowsor@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.Karuturi@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.Karuturi@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.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