debian install system approach
Anthony Towns <aj@azure.humbug.org.au> writes:
> 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".
Well, "boot-floppies" per se is always going to be "just hack it until
it works", because that is a legacy, nasty, end-of-life piece of
software.
To prevent confusion, I suggest you use the term "debian install
system" to mean the install system in general, which is what I think
you mean here, and boot-floppies (or b-f), debian-installer (or d-i)
to mean specific software.
If you review the CVS changelogs for b-f, you'll see the stretch of
time where things weren't really working all that well (until end of
May) were caused by the changes we felt were worth making (replacing
busybox with the packaged version, replacing base with debootstrap)
primarily.
It's pretty much true that any software the decides to make some deep
changes in how it works will subsequently go though a period of
instability. You seem to be wishing there was no period of
instability -- I don't think that can happen.
Another fact you may have overlooked was that my attention at least
was still pretty fixed on the stable updates through the end of March,
2001. Work in earnest on woody began in April.
>From my perspective, that's not all that bad -- functional Woody
boot-floppies in less than 3 months, including adding some new ports
and significant PowerPC bootconfig features. The only reason we were
able to achieve that was because the woody version is an incremental
update only to the Potato version.
In short, I don't see how turnaround could be faster is to have
completely separate teams for post-release stable updates and another
team working on the next release. Luckily, we *will* have this
situation in Woody/sid because Joey Hess is driving Debian-installer
and I'm not involved in it (except perhaps for the installation
manual).
However, on the post-sid release, JoeyH will have the same problem
that you're complaining about -- time I spent on post-release updates
to potato boot-floppies ends up pushing back the following release.
> 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.
Again, not splitting stable maint and unstable devel means you're
going to have the same problems (eventually).
> For the moment, what that means is I'm not starting the freeze until b-f's
> start working with a non-frozen base.
What does this mean? I don't understand it...
What criteria must be met before you will freeze base?
--
.....Adam Di Carlo....adam@onshore.com.....<URL:http://www.onshored.com/>
Reply to: