Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of LSimons@schubergphilis.com
 designates 195.66.90.57 as permitted sender)
From: Leo Simons <LSimons@schubergphilis.com>
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Subject: Re: [DISCUSS][PROPOSAL] git workflow
Thread-Topic: [DISCUSS][PROPOSAL] git workflow
Thread-Index: 
 AQHPlK/+YZnlH+8TeUWaa37/4MgtA5utc4oAgABUkYCAAAJyAIAAAvWAgAADloCAAAhQAIAAAm+AgAACqQCAACY0AIAADVeAgACSOICAACADgIAABNYAgAAhrICAAAGZAIAAClQA
Date: Thu, 24 Jul 2014 09:22:34 +0000
Message-ID: <D02DE026-E5B2-402C-B13A-D39934468372@schubergphilis.com>
References: <A1726C83-4439-4391-8E6D-73DAB815266E@citrix.com>
 <CACOnxCj+3ZSsJ=haf7yLuONav6xUqX9K6tyBUJLbHUBHKJcBHg@mail.gmail.com>
 <85B56B1AEDD2674A82DEC8B61E12182930D691@AMSPEX01CL01.citrite.net>
 <CACOnxCiYS+awYZ1LDfu98P4QOCJZYC_hxOgxpCHbbaJ1mym8sw@mail.gmail.com>
 <CA3230D3-427E-40A9-9898-2FF9B0760250@citrix.com>
 <3A3E69CA-D21B-4F3E-835D-EAD91765A7CC@citrix.com>
 <CALFpzo4SJRpPNE5=n-_-YuDv-oOS4LiP=Ou266-yC9ip3YxcMg@mail.gmail.com>
 <BF2BCFE3-4257-4245-8882-F1A3F3F76A0A@citrix.com>
 <02D48BBC-A209-418D-9263-BDEF88E77A10@gmail.com>
 <A34B0908-8A89-4EC7-A68C-9B8F31A5E614@schubergphilis.com>
 <CAEdis5_Q8dtFhyipWty6KHJk_akEhdih+zxyyrdT3HkGGUcGoQ@mail.gmail.com>
 <18633580-1245-430C-A4DF-5853177F9C97@gmail.com>
 <CAGQtxvaCSbV0dsnwdHXaoRz_2vmCUnndp67VNroa9=MqHUnZ7g@mail.gmail.com>
 <080A05D2-DD56-4737-A5C7-48DD11D0E30F@gmail.com>
 <CAF-TLWqBBJWFk8w+GDjnYGw62Vur7GS5sVWve42kQCSdXQiQAg@mail.gmail.com>
 <E02D298B-259E-41CA-97DE-7F1BFD07FE97@gmail.com>
 <D40B7805-F774-488E-9BCB-20B9ECD2AFD7@gmail.com>
 <CAGQtxvahWpX9jRM2-z5dxDkpLqwFufyrhkpA5QAqsbgKVZaK=Q@mail.gmail.com>
 <CACOnxChbF4PedWWGwfc3srC-ALc7=v=LRz1_sQo06m1=uPGyKg@mail.gmail.com>
 <6A7BE8FE-0225-4C2B-B33C-F5D93E9CADA6@citrix.com>
 <CAGQtxvazZ6MkzWiiZwKhkuPeaZu-ehwXbqJ-A7vqM3XPVspuTg@mail.gmail.com>
 <056F8BBA-DB46-4351-A9E1-666A90A52F35@citrix.com>
 <F528F70F-74BA-4D07-A36C-DD2F52505887@schubergphilis.com>
 <CAGQtxvbAPMUymJ5OJXn_H52KDpLuL9XivhhkjfrLmgS0wVgbGA@mail.gmail.com>
In-Reply-To: 
 <CAGQtxvbAPMUymJ5OJXn_H52KDpLuL9XivhhkjfrLmgS0wVgbGA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <5C8F1B727E93F04FAE8AEA80F0EAE596@schubergphilis.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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`
* =91abandon=92 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-for=
ward has additional tests, lots of changes to test suites, things that shou=
ld 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/ bran=
ches, 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=92t 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=92t 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=92t 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.)
>>=20
>> Starting git-flow from 4.4 or 4.4-forward and then merging things in fro=
m 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 feasib=
le; git cannot un-pick what happened so it cannot offer much assistance.