Anthony AJ.Towns [aj@azure.humbug.org.au] Debian release manager az imént postázta a debian-devel-announce -ra a soron következő Woody kiadási státusz frissítését.Leírja benne, hogy van néhány csomag amit biztonsági szempontból frissíteni kell, rámutat, hogy senki nem szervezi még a Debian mini-conferenciát, amely 2003-ban lesz Perth-ben.
Ezenkívül felvázolja a jövő dolgait:
- befejezni a Woody tartalmát (biztonsági javítások, basedebs.tgz frissítése, stb.)
- elkészíteni a Cd imageket
- megvalósítani az archívum változtatásokat (woody és woody-proposed-updates)
- belőni a mirrorokat, szétküldeni a bejelentéseket
- stb.
Ír mindenről, csak éppen arról nem, ami minden Debian felhasználót a legjobban érdekel. Hogy mikor lesz Woody release. Nem mintha sürgős lenne, de a már _release status_ akkor legalább homályosan célozhatna egy időpontra.
A levél:
From: Anthony Towns
To: debian-devel-announce@lists.debian.org
Subject: [2002-07-07] Release Status Update
Date: 06 Jul 2002 16:30:21 +0200
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
