On Thu, Jun 21, 2001 at 02:43:46AM -0400, Adam Di Carlo wrote:
> Anthony Towns <aj@azure.humbug.org.au> writes:
> > > base because boot-floppies are ready for it.
> > That's not going to happen particularly quickly, because -testing *isn't*
> > ready for it, because they haven't had a chance to get into the swing
> > of things, because they haven't had boot-floppies they can try out and have
> > kind-of work. (2.3.5 came close, but we followed within a day or two by
> > groff and man-db breaking)
> I have to say, you're logic is rather backwards.
> Pretty much *every* reported problem about the installation I've seen
> as far back as 2.3.4 has nothing to do with boot-floppies themselves
> and everything to do with immaturity and instability in base and the
> testing distribution in general.
That's very true. boot-floppies haven't matured at all how I expected:
I was expecting to get something that kind-of worked much sooner, and
getting support for other architectures much later. If my expectations
had been more in line with reality, we might've been able to organise the
-testing group so that they'd gotten some experience with the previous
boot-floppies. But that didn't happen, so too bad.
Anyway, the logic isn't backwards, it's just looking more at getting
things right in the future than at the moment. In particular, for
future releases we need to get in the habit of always having working
boot-floppies, even when we're not expecting a freeze for some time yet.
The benefits of this are mainly in that it gives us more flexibility
in choosing when we freeze and when we release: we don't have to worry
about spending six months getting boot-floppies working again, and we can
change the boot-floppies development philosophy from "just hack it so
it works" to "make it pleasant and functional". The same thing applies
(probably moreso) to debian-installer. Hopefully the d-i architecture
will make it easier. We'll see, hopefully.
What this means is we've got to be able to develop boot-floppies
even in spite of instabilities in the base system. So we've (I've)
got to be debootstrap so it doesn't break as readily with changes in
the base-system; and we've got to work around problems with busybox and
whatever else.
Again, the idea is that after woody -boot will be able to continue
working on the installation system, and -testing will be able to continue
testing upgrades and new installs for the next release, even as it's
under development.
That's not even remotely trivial to make happen, but I'm entirely confident
that it's worth the effort.
For the moment, what that means is I'm not starting the freeze until b-f's
start working with a non-frozen base.
(The astute subscribers to this list will notice that's happened)
> If Debian is willing to purchase for me fast machinery (i386
> preferred) with fask disk and full exclusive root access, i could
> probably do the i386 builds myself much more quickly.
That's not implausible. It's probably worth mentioning to BenC.
Anyway, I don't mean to suggest that -boot's sucking or anything. Indeed,
it's going great: there're i386 floppies that work, there're floppies
for every archi but alpha some of which are even rumoured to work. The
install (if you choose a method that's supported) was quite smooth. That's
substantially beyond where I'd hoped we'd be right now, which means we
should release with a pretty high quality install.
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.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpXubucku6nh.pgp
Description: PGP signature