On Sat, Feb 8, 2014 at 3:26 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> 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
