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

[2002-07-07] Release Status Update



Hello world,

As most of you will have noticed by now, ISS and Theo de Raadt have
been kind enough to provide some stress tests for the new security
infrastructure we deployed last month. The outcome seems to be that
there're a few bugs and a few misfeatures that we'll need to fix, but
that it's nevertheless entirely adequate for its primary purpose. Updates
for the following packages in woody have been made with the new security
system:

    apache                  fetchmail               mozilla
    apache-perl             fetchmail-ssl           nn
    apache-ssl              galeon                  openssh
    bind                    libapache-mod-perl      openssh-krb5
    bind9                   libapache-mod-python    popa3d
    bugzilla                libapache-mod-ssl       squid
    courier                 mailman                 xchat

[0]

As far as the -woody-sucks email went, there were a number of relatively
minor issues raised. It's resulted in about 17 packages being updated
in woody so far, with a few more still due to be updated, and a few
others that will only be dealt with in a point release. From an overall
perspective, none of the issues are terribly serious, and none of them
are showstoppers.

Right now you're probably checking to see where the dists/stable symlink
points, and asking yourself "if those aren't the showstoppers, what
is?" Well, maybe you weren't, but I did, and here are my answers:

(1) There's still a sizable backlog of security problems that need
    fixing. Packages with bugs in the BTS include:

	chdrv       138062
	nocc        147213
        slashem     147120
	nethack     147166
	ktalkd      147762
	sharutils   149454
	courier-ssl 149928

    There're about eleven more in addition to those. The security team
    are working through them, so hopefully we'll have the known security
    bugs in woody down to zero or thereabouts fairly soon.

(2) Nobody's yet organised a Debian mini-conference for linux.conf.au
    2003 in Perth. (*gasp*!) It's relatively easy to do since most of
    the work (organising the venue, accomodation, registrations etc) has
    already been done as part of linux.conf.au proper, so all you need
    to do is setup a web page and pester people into giving interesting
    talks. So, ask not what your woody can do for you, and contact the
    organising committee now!

And that's pretty much it. Once those two issues are dealt with, we'll
be going through (roughly) the following process:

	a) finalise the contents of woody (include any security updates
	   that haven't made it in, any last minute -woody-sucks things,
	   update basedebs.tgz, etc)

	b) prepare CD images

	c) make the appropriate archive changes to make woody and
	   woody-proposed-updates be treated as stable/proposed-updates
	   instead of potato, create a new testing suite, etc...

	d) pulse the mirrors, send out announcements

	e) make another bold guess at woody's release date, and hope that
	   for once I'm not too far off

	f) flame^H^H^H^H^Hpolitely discuss how we should handle the
	   next release cycle, and what's the point of stable, and who
	   should use testing, and so on

Note that you probably won't see any official word until (d).

If you want to prepare a little for (f), you might want to think about
the issues raised in:

	http://bad.debian.net/list/2002-May/001887.html  [and followups]
and	http://www.debianplanet.com/article.php?sid=721&mode=thread&order=0

You might also want to think about things like:

	* What could we do to make "testing" more useful?

	* Why would anyone run "stable" instead of "testing"? Is there
	  anything we can change to allow people like that to run
	  "testing"? (Iterate, end up with a list of neat features to
	  work out how to support for "testing", and a bunch of things
	  that people actually find useful that make it worth going
	  through this much agony every year or so)

Cheers,
aj (woody release manager)

[0] Some random technical details. For developers: since the security
    archive is handled in parallel to the main archive, "madison"
    doesn't work on it, and you need to use "sec_madison" instead. It's
    in /usr/local/bin on satie. Uploads to security, by and large, are
    making there way across to the appropriate proposed-updates suite on
    auric or pandora, however in some cases the new versioning checks are
    causing problems: newer versions have to be _installed_ into unstable
    before the security update can be _accepted_ for testing or stable.
    There also seems to be some annoying problems with the queueds that
    move the uploads from one host to another as necessary, related to
    RSA keys.

-- 
Anthony Towns <ajt@debian.org>

Attachment: pgpFvXEioYkTA.pgp
Description: PGP signature


Reply to: