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: [DISCUSS][PROPOSAL] git workflow
Date Thu, 24 Jul 2014 11:37:28 GMT
It makes sense to me now. +1 from me

one minor thing i would like to add is git-flow doesn’t force you to its naming convention.
You can choose any and stick to it. But, it makes sense to use the defaults.

~Rajani



On 24-Jul-2014, at 2:52 pm, Leo Simons <LSimons@schubergphilis.com> wrote:

> On Jul 24, 2014, at 10:45 AM, Daan Hoogland <daan.hoogland@gmail.com> wrote:
>> Any advice on our procedure from this, Leo?
> 
> Yes, to follow all the git-flow defaults [1].
> 
> * goal is for master to become stable
> * new develop which starts from master
>  * create with `git flow init`
> * ‘abandon’ 4.4 / 4.4-forward
>  * anything in there which is not currently
>    in master gets cherry-picked into develop
>  * accordingly, plan is no 4.4.1
>  * if 4.4.1 becomes really necessary, create
>    it by cherry-picking from develop
> * keep 4.3 to produce 4.3.1 then
>  abandon it, too
> 
> It is important to realize that a git-flow release/4.5 is _not_ the same as an old-style
4.5-forward; a lot more discipline is required.
> 
> 4.4-forward contains a lot of things which are not purely bugfixes. 4.4-forward has additional
tests, lots of changes to test suites, things that should go in 4.4.1 but not 4.4.0, half-merged
features that were pulled from 4.4 but remain in 4.4-forward, bugfixes that include refactoring,
etc etc. In a git-flow model, those things would go onto feature/ and/or support/ branches,
and from there to the develop branch, and definitiely _never_ onto a release branch. It was
very hard to get 4.4 stable by cherry-picking from 4.4-forward; the discipline suggested by
git-flow is _exactly_ to avoid that difficulty.
> 
> Note git-flow defaults also include:
> * feature branches are called feature/feature-thing
>  (don’t put your name in there, its meant to be
>  descriptive!)
> * release branches are called release/{version}
>  (not RELEASE-{version})
> * hotfixes are called hotfix/{version}-name
>  and are based on & merge to master (not usually
>  to a release branch, release branches are not
>  hot, hotfixes are patches to previous releases,
>  i.e. 4.5.1, 4.5.2, 4.5.3 will be hotfixes)
> * everyone can commit on release branches,
>  everyone can merge to develop (generally you
>  don’t need much merging to release branches
>  since the only thing you commit there are
>  bugfixes, you merge _from_ the release branch
>  _to_ the develop branch), merging is _not_ a
>  release manager's job (the release manager might
>  review or approve bugfixes, but its the committer
>  that merges)
> * no cherry-picking!
> 
> 
> cheers,
> 
> 
> Leo
> 
> [1] unfortunately, the reason I did this analysis work yesterday was to try and find
a way to start from 4.4 and go forward from there, first merging in 4.4-forward and then master,
but I don’t see that happening
> 
>> On Thu, Jul 24, 2014 at 10:39 AM, Leo Simons <LSimons@schubergphilis.com> wrote:
>>>             branch two    diff size   big diff chunks
>>> branch one
>>> 4.3         4.4           11MB        hyperv,netscaler,server,engine
>>> 4.4         4.4-forward    2MB        tests,marvin
>>> 4.4-forward master         6MB        xenapi,xen,xenserver,storage
>>> 4.4         master         8MB        xenapi,tests,marvin,xen,xenserver
>>> (See below how I got the numbers.)
>>> 
>>> Starting git-flow from 4.4 or 4.4-forward and then merging things in from master
means processing hundreds of thousands of lines of diff. Of those lines, many many thousands
of lines will probably not auto-merge due to the cherry-pick approach. A rebase between any
of these branches is not feasible; git cannot un-pick what happened so it cannot offer much
assistance.
> 


Mime
View raw message