After doing a lot of thinking at the vet this weekend, I just do not
see how we have the man-power to meet a 'super'-stable release model.
Super-stable requires a lot of effort to review and backport changes..
which is why many of us are paying 'Red Hat' or some consultant with
CentOS/SciLin to do for us. I do not see how we can do so without a
similar revenue stream to pay for people to sit and keep stuff from
bit-rotting or forcing updates to newer versions because the code
between 1.0.1 and 1.0.2 changed over 30%.
It is also hard to know what is 'stable' enough for some groups. For
everyone who wants to keep rt3 at an old version there are those who
want a newer version because it has the features they need. The only
solutions I could see to this were:
a) giving people the tools to easily stick to what they want (in the
way that Dag says for people wanting older stuff from him to use mrepo
or similar to make their own local repository... not that many people
do that... but those who were warned don't get much sympathy .)
b) make it possible to have multiple levels of support when the
bodhi/plague system is implemented. What I was seeing is that we have
say 4 channels:
alpha -- stuff from Fedora is built just like anything else for
EL-4,5,6 and is either 'blacklisted' or 'eats-babies'
beta -- stuff voted as being good enough is put here (eg EPEL-testing).
gamma -- stuff voted to here is good enough for production.
delta -- the last item from gamma is moved here... people can keep
track of old items via this.
epsilon -- really stable releases are here.
the progression is then open to people and they can become involved by
lobbying to keep something in gamma or moving it to delta.. elections
would be held on a monthly system for items they wanted. of course
this is all pie in the sky at the moment.. but worth looking at
anyway, back to the vet.
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"