community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: How can we support a faster release cadence?
Date Sun, 09 Feb 2014 06:40:26 GMT
On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly
<> wrote:
> 72h for a vote is not a hard and fast rule (you just need a good reason for
> why you are going shorter and from what I have seen, the board would
> probably be ok as long as protections are put in place to safeguard the
> community)

By now, I think that we've demonstrated in this thread that scheduled votes
with a small window (12-24 hours) are practical.

Additional tooling could make release review easier, and it would take days or
weeks to set up, not months.  The tooling would be done by the project PMC,
rather than Infra, so we aren't even blocking on additional infrastructure
feature requests -- Jenkins/buildbot and gitpubsub/svnpubsub suffice.

> So the only hard rule per se, is that the PMC must do their IP diligence...

Beyond the legal aspects of making a release, voting is also necessary to
demonstrate that a release has community consensus.

The area we still need to explore, IMO, is what happens when release votes
fail, as that may disrupt the schedule.  In a worst case, a release cycle
might have to be skipped.  Subsequent releases would carry a greater payload
of accumulated work, increasing the bug surface area.

I think we have to accept this possibility.  A community can have a "bias to
ship", but that bias cannot be so strong that it overrides a majority vote
rejecting a release candidate.

Things might spiral out of control if we allowed vetoes on release votes...
but we don't.

If a community is experiencing frequent glitches, that just means
insufficiently mature code is being merged into the mainline too aggressively.
That's easily remedied by dialing back the pace of feature integration.

Marvin Humphrey

View raw message