cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [PROPOSAL] Move to github PR only during moratorium on commit
Date Mon, 20 Oct 2014 18:28:55 GMT
Thanks. Question for Sebastien then. The argument is that this new proposal will avoid problems
such as
 - broken builds. Presumably this is  test failures (don’t recall a compile-time failure).
How exactly would this be achieved WITHOUT a CI process?
 - delayed releases. Not sure how this fixes it. Seems like it is just introducing a bottleneck
for the sake of slowing things down?
 - features merged without warning. Warnings are good. But what does one do with (let’s
say a 3-day) warning? One must trust the developer or trust the developer and the CI system.

The argument it seems is for a stable master vs a stable release branch.  Is that the correct
summary? Why not switch to that model on ACS git instead of GitHub?

From: Daan Hoogland <<>>
Reply-To: "<>" <<>>
Date: Monday, October 20, 2014 at 10:34 AM
To: "<>" <<>>
Subject: Re: [PROPOSAL] Move to github PR only during moratorium on commit

No Chiradeep, Pull of the request will still be on the local committer repo
and pushed to ASF infra (wip)

On Mon, Oct 20, 2014 at 7:26 PM, Chiradeep Vittal <<>> wrote:

Won’t this proposal make GitHub the canonical repository? I don’t see ASF
infra being too happy with that.

From: sebgoa <<><>>
Reply-To: "<><>"
Date: Saturday, October 18, 2014 at 2:00 AM
To: "<><>"
Subject: [PROPOSAL] Move to github PR only during moratorium on commit

After [1] I would like to officially bring up the following 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.

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.

Our development and release process is broken, we cannot continue like
this, let's fix it.




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