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 terbolous@gmail.com designates
 209.85.218.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5D7C3B65-4B76-4B8B-B22C-F5CF1AF8846A@gmail.com>
References: <5D7C3B65-4B76-4B8B-B22C-F5CF1AF8846A@gmail.com>
Date: Mon, 20 Oct 2014 19:25:17 +0200
Message-ID: 
 <CAP997UcQEZUUypw-YjMNvEUDw6rXYNh5Gar3xoiSGjbsbg_ZaA@mail.gmail.com>
Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit
From: Erik Weber <terbolous@gmail.com>
To: dev <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=089e011828629a88e40505ddff46

--089e011828629a88e40505ddff46
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 18, 2014 at 11:00 AM, sebgoa <runseb@gmail.com> wrote:

> After [1] I would like to officially bring up the following proposal.
>
> [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 warnin=
g.
> 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:
>
> [Reasons]:
> ----
> 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 maste=
r
> (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.
>
> 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 (b=
e
> it master).
>
> 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) woul=
d
> be reverted immediately.
> ----
>


I'm +1 to any change that could improve quality, and submitting to github
as non-committer is a magnitude faster/easier than RB.

--=20
Erik

--089e011828629a88e40505ddff46--