On Sun, 16 Nov 2003 02:23:00 +0100, Adrian Bunk wrote: > You need a freeze at one point (unstable or testing) to get a base > where you can start to fix the remaining problems without new bugs > from new upstream versions.
> The choices are: > - freeze testing and start then to backport all the bug fixes and > security fixes from unstable > - freeze unstable and try to get as many packages as possible from > unstable into testing (exactly the work you are currently doing, but > based on a more stable basis) > - freeze unstable and use unstable as a basis How about changing the way testing works? I mean, we've come to the point when we realize that the testing/unstable structure is not really working, so we added experimental. Now, I suggest: allow a way to add bug-fixes directly into testing, instead of having them go through unstable first. If there's a new (and very buggy) version in unstable, but there's an easy-to-fix bug in testing, why not allow developers to fix this bug without going through the unstable barrier? I'm not a developer, I consider myself a Debian bug-reporter. And I usually report bugs for testing, and many times I've received the reply "this is fixed in unstable", but then unstable never comes because there are LOTS of other bugs. So, why not allow the bug-fixes to go into testing, even if the new version does not come? I'm not talking about some manual security update, I'm talking about a systematic way of doing it. For sarge and for the next release as well. I don't know how to implement this, but I think it would be a great idea to allow it, so that testing packages would get less and less buggy, no matter what happens in unstable. Love, Margarita Manterola. PS: As a Debian user, I would really hate to see sarge released as it is right now. I consider an insult to the user that "Evolution" is not in the release (not even the old woody version). But this is outside my present suggestion.
