[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: My freeze date estimate

On Tue, Jun 17, 2003 at 03:24:14PM -0500, Drew Scott Daniels wrote:
> - The gcc 3.3 transition needs to complete (3 months?)

I don't think it needs to be absolutely complete. If some programs, or
even some libraries, are still linked against libstdc++2.10-glibc2.2
then so be it. We should fix as many of the new build failures and
uninstallabilities as humanly possible, though.

> - Gnome2 should to go into testing (1 month?)

Getting there; we now have gnome-panel and gnome-session, which help but
aren't anywhere near complete. A quick cobbled-together status on those
of gnome-core's dependencies which are still GNOME 1 in testing:

  control-center: gnome-pilot and xscreensaver need a few RC bugs fixed
  so they can use the new libpanel-applet. gnome-pilot depends on a new
  pilot-link, which needs perl, which needs gdbm, which needs openldap2.
  We could probably ditch ppxp-applet and xalf if they're not updated by

  gnome-applets: Random build failure on s390 which looks transient;
  dependencies on bonobo-activation, libbonobo, libbonoboui, gconf2, and
  gnome-vfs2, most of which are just matters of time (although what's
  that segfault in libbonoboui's m68k build log?).

  gnome-terminal: Another of those build log segfaults on m68k, and
  needs fontconfig.

  nautilus: Needs everything that gnome-applets needs plus eel2, and is
  out of date on various architectures.

  gnome-media: Waiting for build-dependencies on various architectures.
  Needs gst-plugins which seems to be a world of pain; effort is needed
  on its RC bug and on all the stuff blocking jack-audio-connection-kit
  from testing.

We need at *least* that before we can start saying that GNOME 2 is in
testing, but I think we'd really rather have all of the gnome package's
dependencies, which adds abiword, balsa, evolution, gnucash, and
gnumeric to the list above.

> - KDE should go into testing (4 months?)

kdelibs also requires openldap2, and both it and kdebase have their own
collections of RC bugs. I'm not sure it's worth putting much effort into
the upper strata until the basic packages are less buggy.

> That being said we (the RM actually) could call the exsisting installer
> finnished, treat the gcc 3.3 transition issues as RC bugs (as they are,
> including the XFree86 ones), throw Gnome2, KDE, apt and dpkg into testing
> and call a freeze...

Throwing GNOME 2 and KDE 3 into testing right now would involve ignoring
a number of release-critical bugs and rendering them uninstallable on a
number of architectures. I'm not sure this is a good idea.

Far more importantly, we need to be getting into the freeze mentality
Real Soon Now: no more major changes (particularly not in packages
involved in complicated dependency chains), and push for stability. Over
900 RC bugs is a ridiculous point from which to start trying to freeze,
but we're going to have to try it.

Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: