Re: State of the Woody
On Tue, Dec 19, 2000 at 02:35:43PM +1000, Anthony Towns wrote:
> 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.
Are we in such a hurry ? We can wait for the new installer a few more months.
BTW, why have we always gone with *male* character names in Debian ? Looks like a very sexist attitude !
Eric
>
> 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
--
Eric Van Buggenhaut - evanb@competitiveness.com
Please don't send proprietary format documents, I can't open them.
Use instead open-source formats like .txt or .rtf. Dvi, ps or tex files are welcome.
Reply to: