Re: Re: Some observations regardig the progress towards Debian 3.1
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.
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