On Fri, Mar 26, 2004 at 01:42:50AM +0100, Adrian Bunk wrote:
> Before testing was invented, it was also a goal that testing should be
> always in a releasable state. Practice has shown that this goal was
> never reached.
Uh, the phrase is "has not been reached".
There are two main reasons for that: one is it's essentially impossible
to install testing, although we might see that one solved after sarge
is released with d-i. The other is that there's no security support
for testing, and there's still no prospect of that changing.
> Looking at the woody freeze, the question arises whether testing really
> reaches the goal to reduce the freeze time.
The "freeze time" that matters is when the last round of upstream
changes and other non-RC fixes make it into the stable release; which
is to say the amount of time developers can spend on development rather
than cleaning up messes.
> There are always reasons to say "hey, we managed to get A, B and C into
> testing, and the next goals are getting D, E and F into testing". But is
> this real progress towards the next stable release, or will after F is
> achieved only G, H and I arrive?
The only thing that really matters is having a working installer; we
haven't had that since woody released, and we still don't have it.
> I have yet to see any objective evaluation whether testing really is an
> improvement.
potato's release was held up by RC bug fixing -- b-f's was working
fairly well for months before it released; woody's release was held up
by getting a working installer, and then getting the security stuff done;
sarge has been utterly blocked waiting for a working installer.
> I reassigned from Debian over two years ago since I was not happy with
> the speed of Debian releases. Since then, I have the impression things
> got even worse.
I don't believe "Adrian Bunk" was ever identified as one of the major
blockages in Debian releases. But hey, at least you don't have to take
any responsibility for any of the problems!
> It's quite frustrating that there's no clear schedule towards Debian 3.1
> that includes a date for the beginning of the freeze.
>
> When talking about a clear schedule, I'm not talking about something
> unrealistic like the schedule that told Debian 3.1 would be released on
> Dec 1st 2003 that included dates that were not based on any realistic
> estimates (esp. the installer dates).
Any estimate that predicts how development work goes isn't going to be
accurate; the only way you get good schedules is by letting yourself
make the schedule /independent/ of whether development gets completed
in a timely manner or not. testing aims to do that for most of the distro:
it lets people who can make stuff work quickly keep uploading on their own
schedule, and people who can't get dropped and kept out of the release until
they fix their bugs.
What it doesn't and can't do is ensure that we have a working installer
while we continue to redevelop it every release; and it likewise can't
ensure that infrastructure, be it security related or otherwise, is
working if it isn't hooked into the testing process.
> Most frustrating is that I see no way to help making the situation
> better at the moment.
Make the installer work well. Work on security support for testing.
> Fixing bugs is not very effective as long as
> there'a no freeze and new upstream versions with new bugs flood into
> testing every day.
If you think this is a major problem work on ensuring programs with bugs
are found and fixed in unstable, or beforehand.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we could.
http://conf.linux.org.au/ -- Jan 12-17, 2004
Attachment:
signature.asc
Description: Digital signature