How about if it meets the folowing critieria:
1. it has been in testing for 10 days (been in sid at least 20 days)
2. the version is sid is the same as in testing (the maintainer has not
found problems in the ten days since it entered testing)
3. and has no RC bugs (no rc bugs reported in the ten days it has been in
testing)
4. It fixes security or stability bugs (whose fixes would normally be
backported) that cannot reasonably be backported.
Then (at the discretion of the maintainer) it can be:
1. uploaded to stable-proposed-updates (it will only get in to stable with
stable RM's approval)
OR
2. Iff it fixes a critical security problem, uploaded to security (This
requires security team and/or stable RM approval).
This makes sure it is fairly stable, yet allows bugs in programs like
mozilla (when the new upstream version should only be fixing bugs anyway).
------
I think the no new upstream versions is stable rule needs to be more
flexible anyway. I have seen times where EVERY SINGLE change except for the
version number have been backported. That is often the case where the new
release consists of nothing but the desired changes. In those cases it is
illogical not to just go with the new versions.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
