The other open source efforts I'm involved with use a rough consensus
process to do a release. If people have "-1" opinions, they are heard
and addressed before a final consensus decision is reached.
> And the people "voting" are core contributors who we would hope would
> put the interests of the community ahead of their personal interests.
In practice, other projects seem able to do this.
In fact, the JMRI model train community is actually having a release
conversation as we speak :-) It sounds like this:
A Core Person: "I think we should have a release soon because
[reasons]. What do y'all think? In particular, what still
needs to get done?"
Developer1: "I'm still working on [bugid], which needs to be in the
release because [reasons]. It should be done in a week."
Developer2: "We should schedule the RC for Thanksgiving so that people
will have time to try it and get bug reports back to us. We
also need to have the real thing out by the holidays, because
[vendor xyz] is ramping up new hardware for a big holiday
sales push, and it needs the new driver code in the CVS tree."
Developer3: "I'm working on [rfe], but it isn't ready for prime time,
so I'll hold off putting it into CVS so as to not impact the
release."
Of course, the question is raised only with the core developers on the
JMRI project; neither the user community nor the developers of component
parts (RXTX, Java, log4J, JUnit, ...) are directly consulted, even though
some components are co-resident projects on sourceforge....
Translating this back to OS.o brings us back to AlanC and Keith's
OGB efforts to better define Consolidations. At some point, distros
should be built out of a set of consolidation-driven binary releases,
and not snapshots in time of source code across multiple consolidations.
-John
