cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: [PROPOSAL] Move to github PR only during moratorium on commit
Date Tue, 21 Oct 2014 23:21:58 GMT
Hi Sebastien:

So I like the idea of:

1. Us putting up all inbound code for review.
2. Gating that code on a testing pass
3. Having someone else look at it before committing.

I don't think that should mean that all code that works gets an
immediate pass. I also don't think that we should have n RMs for
branches. It doesn't scale, and it moves us from consensus to
authoritarian. I am all for reverting things that break, but think
that should be a community wide responsibility, not one or two

I also think this is a huge shift in process. Right now we have 145
open patches on ReviewBoard. We average scores of commits per day; so
understand that this is a huge, gigantic shift in how we work. This
requires a high level of commitment from everyone, and frankly it's
likely to bury TravisCI.

I also worry about the effect of this on our ability to timely ship
4.5. We have 14 Critical and blocker bugs for 4.5, and part of me
worries that this is a distraction for 4.5 release efforts.

Please don't take this as discounting your proposal or your concerns.
I don't think that many folks disagrees in principle with the first 3
points above. But timing, and implementation details may be an issue.


On Sat, Oct 18, 2014 at 5:00 AM, sebgoa <> 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 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:
> [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 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
> 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.
> ----
> Our development and release process is broken, we cannot continue like this, let's fix
> [1]
> -sebastien

View raw message