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

Release Plans (1999-05-10)

(Please send followups to debian-devel, not debian-devel-announce.)

This mail is a summary of issues that affect the next release.  Comments
and feedback are welcome.  It's supposed to be a complete list, so please
contact me if your favourite issue is not listed here.

I realize that I have, so far, not acted as Release Manager in the way
I intended.  I apologize for this, and I promise to do better from now on.

A number of release goals have been proposed.  I don't intend to start
the freeze until all release goals are in place.

  * No release-critical bugs.
Wichert's list shows more than 100 of these.  I'll go through it soon,
and probably downgrade a number of them, and mark some packages for
removal when the Time Comes.  (I'll ask Wichert to count those
separately).  Still, it's going to take some time to fix them all,
and this will probably be the main factor in setting the freeze date.

  * Working disk sets for all released architectures.
I don't know much about the plans for the boot-floppies yet.  Could
someone volunteer as a contact person, or tell me the best list to read?

  * glibc 2.1 upgrade
As far as I know, this project is largely complete.  There are one or two
bugs left in the backward compatibility code, and there's the question
of what to do with /dev/pts.

  * glibc 2.1 source compatibility
A larger task is to ensure that all packages still compile on a glibc
2.1 development system.  The sparc people may have a list of problem

  * PAM
Progress has been made toward a fully PAMified system, with X and
the shadow suite being the main exceptions.  I don't intend to
delay the release for this, but I think it has a good chance of
being completed in time anyway.

  * perl 5.005
I've been assured that a working upgrade plan now exists and is being
worked on, one that will not involve recompiling a lot of packages.
I'll still be happier if perl 5.005 is introduced at the start of
the next release cycle, though.  There's a lot of perl code in Debian
that hasn't been tested with the new version.

  * FHS compliance
This will involve a number of changes that will affect all packages.
There's no consensus yet on how to do this, and I consider it to be
still in the "early plans" stage.  In the meantime, we've been moving
toward FHS compatibility in little ways.

I wasn't there to see it, but I hear that the GNOME staging area has
now been folded into potato and is ready for the freeze.

The freeze is at least one month away, and possibly a lot more than
that.  I'm not going to set a date until the number of
release-critical bugs has been reduced considerably.

  debian-release mailing list:
I think this is a good idea, and I will certainly join such a list.

  Return of the Revenge of Slink:
A Debian 2.1r3 release should be made soon, to fix a number of 
outstanding bugs.  I'll write a separate mail about this.

  Potato Architectures:
As far as I know it will be the same set as in slink, i.e. i386, m68k,
sparc, and alpha.  If any other architectures want to make a release
they will have to decide soon.

  Help wanted:
I'd like someone in charge of chasing release-critical bugs.  This
means mailing maintainers to ask for plans and estimated fix times,
adding comments to Wichert's bugscan list, and telling me which bugs
are probably bogus.

Richard Braakman

Reply to: