Ideas for dealing with less VOTEs per RC

[Chris Mattmann <ma...@apache.org>]

Hi Folks,

In response to your board report for September 2013, I had some
suggestions for dealing with the problem of getting less and less
VOTEs per RC you roll.

 One thing you may want to do is suggest is for the RM to ask the PMC if
their
VOTEs may be "carried through", especially in the case of some minor
update to a new RC that doesn't involve a critical bug fix (e.g.,
an RC only b/c of a documentation issue, etc.) Sometimes this can
solve the stagnation issue. Another idea is to think about a lazy
consensus release model, and to lower the barrier for release
vetting. E.g., see if you can define a "minimum bar" even if it's
simply verifying the sigs, and checksums and building the code for
a +1. If you can get 3 +1s that way, then if you roll releases with
bugs that may motivate folks to spend their extra time testing those
bugs in subsequent releases. Finally, improvements in CI and automated
testing may help here and also in release checking for the basics
(checksums, sigs, and building). If you can script the basics and
provide that to the PMC it may encourage more of them to vote. Just
some ideas.

Cheers,
Chris

Re: Ideas for dealing with less VOTEs per RC

[Justin Mclean <ju...@classsoftware.com>]

HI,

> One thing you may want to do is suggest is for the RM to ask the PMC if
> their VOTEs may be "carried through", especially in the case of some minor
> update to a new RC that doesn't involve a critical bug fix
+1 to that, several RCs have just been README/RELEASE_NOTE or similar low risk changes.

>  Another idea is to think about a lazy consensus release model

There may be some objections to that idea as it my be seen as being a bit risky as we're not good at getting new releases out quickly and don't want to put a potentially buggy release in users hands.

Since the last release we've made the nightly release more easily available and there have been more issues reported by users so hopefully than mean less unknown bugs in the next release.

> Finally, improvements in CI and automated testing may help here
Other than making it easier to debug when a test fails I'm not sure what major improvements could be made here. The CI have reasonable good coverage, but as it's a large codebase some areas are better tested than others. Not many committers have added new tests.

I would also like to see more frequent releases, but not many committers  actually want to be a release manager (AFAIK). It's a large effort to get the code in shape for a release, manage the branching/merging of changes, try and encourage other people to help out, as well as all the post release tasks.

Here the current release process:
https://cwiki.apache.org/confluence/display/FLEX/Release+Guide+for+the+SDK

Anyone see anyway of making this easier or simpler?

Thanks for the ideas.

Justin