cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: merging versus cherry-picking
Date Thu, 16 Oct 2014 10:09:43 GMT

On Thu, Oct 16, 2014 at 12:02 PM, sebgoa <> wrote:

> On Oct 16, 2014, at 11:34 AM, Daan Hoogland <>
> wrote:
>  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.
> ----

I don't like your proposal but agree that such a drastic step is needed. I
will yield to it in favour of a journey towards quicker release cycles.

> 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.
> 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…)
> 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).
> 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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message