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 Thu, 24 Jul 2014 09:22:34 GMT
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