cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Thu, 24 Jul 2014 11:19:37 GMT
now we are kind of set back by this unfortunate result of Leo's work.

new proposal:

We start using git-flow for 4.5/5.0 exclusively.
as of then we will use the workflows as describe by him [1]
4.4.x will still be released by manual RM-cherry-picking (yes
volunteer dragging his feet)

Leo, are you prepared to write up a how-to cwiki page?

kind regards,


On Thu, Jul 24, 2014 at 11:22 AM, Leo Simons <> wrote:
> On Jul 24, 2014, at 10:45 AM, Daan Hoogland <> 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 <> 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


View raw message