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

[2002-06-11] Release Status Update

Hello world,

You should probably read all of this message, or at least skim the first
sentence of each paragraph to make sure you don't miss anything. Oh,
and if it's not the 11th yet where you are, obviously you shouldn't read
this message.

So, presumably everyone who's reading this has already seen the
previous message, which indicated the security infrastructure work we
were waiting on is getting close to done. For those of you who hadn't,
consider yourself updated.

First, I should emphasise that security stuff is *not* yet finished. That
most of the remaining work should be bug fixes and a matter of installing
previously tested software on different machines doesn't mean there's
no work left to be done. We're not going to be releasing in the next
few hours.

We're also not entirely done developing woody. In the previous update,
I indicated that I thought woody was ready to be released. We're now
in the fairly fortunate position of being able to review any problems
that have come up with woody in the month after I made that statement
and see how accurate, or not, it was.

So, the easiest first step in such a review is to see what changes have
actually been made to woody since May 1. They are:

	* a new boot-floppies upload (3.0.23-2002-05-21), particularly for
	  sparc (which couldn't produce bootable CDs with previous b-f
	  builds), and ia64 (which needed a new kernel version)

	* removed packages: (mostly stuff that was requested to be removed
	  from unstable that isn't depended on by anything in woody)
		kernel-image-2.2.20-udma100-ext3-i386 [zlib bug]
                mmix-src [broken, 145534]
                wmspaceweather [147284]

	* binary-only updates to packages on particular architectures to bring
	  them in sync:

	* updated packages (source and binaries across all applicable
		abiword [various minor bugs, update to be > version 1.00]
                apache [security issues]
                arch [security issues]
                base-config [looping problem]
                bind9 [9.2.1-1 CERT]
		brltty [broken init script]
                cweb [145534]
                dhcp3 [security, 3.0.1rc9-1 CERT CA-2002-12]
                dns-browse [security, 147654]
                dpkg [enable force-overwrite by default]
                ecartis [security, argv buffer overflow, bugtraq, 147064]
                eterm [security, 0.9.2-0pre2002042903 bug# 141374]
                ethereal [security, 0.9.4-1 ethereal advisory enpa-sa-00004]
                evolution [security, 1.0.3-3 bug# 145903]
                gaim [security, 0.57 buffer overflow in TOC protocol plugin]
                gal [needed by evolution]
                gdk-pixbuf [needed by gaim and evolution]
                glibc [nscd security issue]
                libnss-lwres [crypto-in-main]
                lukemftp [security, 1.5-7 bug# 146148]
                lvm10 [new lvm systems]
                lvm10 [twice! "downgrade" from 1.1 to 1.0]
                mnogosearch [security, 3.1.19-3 bug# 146720]
                mutt [crypto-in-main, 145770]
		orbit [needed by abiword]
                psycopg [crypto-in-main]
                qpopper [security, 4.0.4-2 bug# 144974]
                rblcheck [145769]
                snoopy [147169]
                squirrelmail [security, 1:1.2.6-1 bug# 144496]
                trafstats [security, 0.4.19-4 bug# 145361]
                webmin [security, 0.94-5 buffer overflow 147599]

A few of these are real problems: the problem with the sparc boot-floppies
and dpkg are relatively serious issues for release and weren't discovered,
let alone fixed, until after May. Likewise, the lvm and base-config
problems aren't really things we would have liked to have had to deal
with after commiting to a release. There're also a handful of belated
crypto-in-main related changes, that should've (and in most cases
could've) been accepted into woody before May 1.

Of the remainder, there are four or five packages that've been updated
or removed at the request of the maintainer that we could've lived with
pretty easily as they were, and a whole host of security updates, that
we generally have to live with maintaining post release anyway.

As far as this goes, it seems fairly reasonable so far. Woody is certainly
a long way off perfect, but it seems to be standing up fairly well,
after a month's scrutiny.


From this point on, security updates should be done entirely through the
security team. They (via the new security software) will make uploads both
to security.debian.org and to the appropriate proposed-updates directory.
If you have a security problem in your package, make sure they're informed
about it. They'll give you any further instructions about exactly what
they'd like you to do from there. Security updates processed before
release will be included in the release.

Otherwise, over the next week or so, I'd like to encourage people to
do their own poking around at woody to see if my opinion strikes you
as accurate. Are there any major issues that desperately need to be
addressed before we release?

If you find some, you should do the following:

	* Discuss it with some other developers to make sure you're not
	  freaking out over nothing. We've got 15,000 open bugs that'll all
	  make some of our users (or some of us) miserable one way or
	  another, and we simply can't do anything about the vast majority
	  of them for woody. Is the problem you found particularly special,
	  or is it just something we need to fix before th enext release?

	* Make sure it's fixable. If there's no bug report filed,
	  file one, and include a full explanation. If there's no patch
	  in the bug report, work out what the problem is and fix it. If
	  it hasn't been fixed in unstable yet, contact the maintainer and
	  make sure it is fixed in unstable. Do an NMU if the maintainer's
	  not able to fix it.

	* Send an email to me pointing to the bug report and making sure it's
	  clear why this problem needs to be fixed in woody. There's a special
	  email address for this, viz:


	  which should get you a much better response than such mails to
	  me have been getting over the past month. Be clear, and concise,
	  but include all the details. You may wish to begin your emails
	  "Woody sucks because...". Once you've done that, you should get
	  a reply indicating whether it really is worth fixing, or not.

	* If it is worth fixing, you'll then need to prepare a
	  "backport" to testing. This means preparing a new version of
	  the package with a different version number (it needs to be a
	  lower version number than the package in unstable to ensure
	  upgrades behave sensibly) and uploading it to "testing"
	  instead of "unstable" (or "frozen" or "woody-proposed-updates").

Presuming we're stay in good shape for a week or so, and can solve any
problems that're found, we'll be looking to release shortly after that.

In the meantime, since we have woody-proposed-updates operational,
and won't be accepting further promotion of packages from unstable to
testing, there's no need to be particularly wary about uploading new
stuff to unstable. So, have at it.

aj (woody release manager)

Anthony Towns <ajt@debian.org>

Attachment: pgppGx0XrghVn.pgp
Description: PGP signature

Reply to: