Linux Today: Linux News On Internet Time.

More on LinuxToday

Debian: State of the Woody

Dec 19, 2000, 04:48 (7 Talkback[s])
(Other stories by Anthony Towns)


How to Help Your Business Become an AI Early Adopter

From: Anthony Towns aj@azure.humbug.org.au
Subject: State of the Woody
To: debian-devel-announce@lists.debian.org
Date: Tue, 19 Dec 2000 14:35:43 +1000

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:

        * 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

        * 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.

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

We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.