Re: State of the Woody
On Tue, 19 Dec 2000, Eric van Buggenhaut wrote:
> 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 !
Bo.
> 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
>
>
>
>
--
Pardon me, but you have obviously mistaken me for someone who gives a
damn.
email galt@inconnu.isu.edu
Reply to: