Hello world,
It's been roughly four months since potato got released, which means
woody's been in existance for eleven months, and that we probably want
to think about freezing and releasing it in a few more months.
So, where are we at?
On the upside:
* we have a package pool now
* we have testing now
* KDE is in main!
* glibc 2.2 almost builds everywhere
* X 4.0.1 should just be dependent on glibc 2.2
* perl 5.6 is almost here
* Gnome 1.2 on its way too
* dpkg 1.7 also dependent on glibc 2.2
* impressive increase in number of packages.
for reference, binary packages in main in each suite:
potato woody sid
alpha 3725 4059 5075
arm 3438 3739 4207
i386 3901 4254 5526
m68k 3656 3981 4760
powerpc 3630 3947 4901
sparc 3720 4039 5105
Coming soon:
* apt 0.4 might make it into unstable before the end of the
millenium [1], along with new console-apt and aptitude frontends
* gcc 3.0
* working glibc2.2 packages on all architectures, and thus lots of
other things being added to woody from sid
Under development:
* debian-installer
* package and release signatures (verifying the integrity of both
individual packages and the entire release)
* debian-jr
* ??? (probably lots of other things)
On the downside:
* debian-installer is still quite a long way from being usable to
do installs; and (not surprisingly) boot-floppies hasn't
magically improved all that much since potato's release. So
we don't have any particularly great method of installing woody.
boot-floppies will take at least a few months simply to work with
woody, let alone to improve at all.
* glibc 2.2 doesn't seem to be built on either m68k or arm
(in actual fact, there doesn't seem to be any libc6 package
in woody for either m68k or arm). gcc needs to be updated
simultaneously with glibc due to the libstdc++ dependencies,
but the current version of it isn't available on either m68k
or poweprc. Most updated packages (including X, perl5.6 and
dpkg) depend upon the new glibc. You can see the effects of
this and other random problems when the testing robot tries
to find stuff it can add to testing:
http://auric.debian.org/~ajt/update_excuses.html
http://auric.debian.org/~ajt/update_output.txt
* we had about 7000 open bugs rated normal or above when we froze
potato, we have about 11000 now (a 53% increase in known bugs
for a 41% increase in (i386) binary packages). Of those, we have
63 open critical bugs, 165 open grave bugs, 12 open serious
bugs, and 570 open important bugs. (Roughly speaking. The
latter numbers count merged bugs multiple times)
So, what're we going to do about all this?
I think our priorities for woody's release are:
* a functional, tested install method
* a functional, tested, documented upgrade method
* a usable, tested system
* lots of NeatNewStuff
Ordered from most difficult to get right to least, not by worth.
So I think the thing we probably need to focus first on is getting some
way to install woody directly. Which means we need to decide whether
we're going to keep hammering away at debian-installer until it actually
becomes usable, or if we're going to bite the bullet and just accept
that we're going to use boot-floppies again, not be able to improve
them much and get flamed for it in all the woody reviews too. If we
do go with boot-floppies for woody, I'd be strongly inclined towards
downplaying debian-installer so as not to divide the testing effort and
leave us with a choice of two installation methods that both suck. To get
boot-floppies to work with woody at about the same quality as potato's
install, will likely take a couple of months; to get debian-installer
to work at a similar quality could take... four months? six?
After we get a working installer (on all architectures, that works
reasonably), I think it'd be good to spend two months or so ironing out
installation issues, so that the install is as pleasant as we can make it.
If we choose to use boot-floppies, this will probably involve freezing
the base packages so the boot-floppies people have a known quantity to
work with.
Once our installer works acceptably, we'll have (hopefully) a short
gradual freeze. So a first test cycle of a couple of weeks where the
installer and base are frozen and the initial install is checked, and
any last minute problems with standard packages are fixed. Then another
test cycle for a couple of weeks with base+standard+tasks are frozen,
and CD images can be built and normal installs can be done, and release
notes can be finalised. And a final test cycle with everything frozen,
and only security fixes added between then and the actual release.
If we choose to use boot-floppies, that would be a timeline something
like:
* Jan, Feb 2001: Get boot-floppies functional
* Mar, Apr 2001: Get boot-floppies usable
* May 2001: Freeze boot-floppies; Freeze stable
* Jun 2001: Freeze optional; Release
Presumably it'll end up getting extended since nothing ever goes to plan,
but that's probably an optimal timeline if we're going to give people
a chance to do some testing on our install.
In addition, we have something of a bug problem: there are still a fair
few RC bugs in testing that probably need to be examined and downgraded
and/or fixed. There are *lots* of RC bugs (and even more important bugs)
in sid, that are obviously preventing those packages from being released.
Neither of these are good. It might be worth giving the -qa team leeway
to say `If the bug's been there for two weeks, been marked as RC for two
weeks, and you haven't made any uploads or said anything particularly
helpful in the bug log, and the -qa team can fix it, they'll do an NMU
without waiting a further week or two for you to say it's okay'. That is,
to consider an RC bug report itself all the advance notification that's
necessary for someone to NMU the package.
Discuss. 10,000 words or less. On my list by Monday.
Cheers,
a "which Monday?" j
[0] http://auric.debian.org/~ajt/
There's even a link to some actual explanatory stuff now too, albeit
not all the much.
[1] ie, 2999. In the meantime, it's at http://people.debian.org/~jgg/apt/
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgp2147LYwpUs.pgp
Description: PGP signature