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 runseb@gmail.com designates
 209.85.212.173 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: merging versus cherry-picking
From: sebgoa <runseb@gmail.com>
In-Reply-To: 
 <CAGQtxvb4VA1q+E53wxJ+vgZFiuyUW3p2-mZ_s=m+BpcDajukgQ@mail.gmail.com>
Date: Thu, 16 Oct 2014 12:02:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5ADD6986-DB3C-4894-82D9-BC42A81AFCBA@gmail.com>
References: 
 <CAGQtxvb4VA1q+E53wxJ+vgZFiuyUW3p2-mZ_s=m+BpcDajukgQ@mail.gmail.com>
To: dev@cloudstack.apache.org


On Oct 16, 2014, at 11:34 AM, Daan Hoogland <daan.hoogland@gmail.com> =
wrote:

> H,
>=20
> I noticed a lot of commits on master and 4.5 without any links between
> them. These could have all been committed on 4.5 and merged back into
> master leaving a trail of prove that the same code is in both =
branches.
>=20
> It hurts to see this happen. we are at a brink where we can improve on =
our
> way of working. Let's do so. I will do a test merge-back of 4.5 to =
master
> to see how big the damage is=E2=80=8B.
>=20
> --=20
> Daan

Daan I am +1000 with you on this, we need to come together as a =
community and change these practices.

I would like to make one clear proposal to move us forward (outside of =
this thread if I see that a few folks agree).

Proposal:
----
All commits come through github PR, *even* for committers. We declare a =
moratorium period (agreed suspension of activity) during which direct =
commit to master is forbidden.
Only the master RM is allowed to merge PR in master (we define a master =
RM). If direct commit to master is done, master RM reverts without =
warning. Same for 4.5 and 4.4. branches.
----

This is drastic and I am sure some folks will not like it, but here is =
my justification for such a measure:

Our commit and release processes have so far been based on the idea that =
development happens on master and that a release branch is cut from =
master (unstable development branch). Then a different set of community =
members harden the release branch, QA and bring it to GA level. During =
that time development keeps on going in master.

This is an OK process if we have the luxury of having a QA team and can =
cope with split personality of being developers and release managers.=20

My point of view is that as a community we cannot afford such a split =
brain organization and our experience overt the last year proves my =
point (delayed release date, broken builds, features merged without =
warning=E2=80=A6)

We can avoid this by cutting a release branch from a stable one (from =
the start), then as you (Daan) have mentioned several times, fix bugs in =
the release branch and merge them back in the stable source of the =
release (be it master).=20

Feature development need to be done outside master, period. Not only for =
non-committers but also for committers. And merge request need to be =
called. This will help review and avoid surprises.

New git workflow were proposed and shutdown, mostly calling for better =
CI to solve quality issues. CI will not solve our quality issues alone. =
We need to better police ourselves.

To avoid long discussions, I propose this simple but drastic measure. We =
move all our commits to github PR until 4.5 is out, this stands for =
committers and non-committers, direct commits (especially to master) =
would be reverted immediately.

-sebastien