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

release adjustments


as you (probably) all noticed, we delayed the full final freeze of Etch a
bit. This mail contains important information what you should do as
maintainer of any frozen package (which will be all packages soon), please
read at least this part. Also, please don't upload changes that are not
meant for Etch to unstable. You can of course use experimental for any
changes, however experimental they are. Also, please don't do any shlib
bumps anymore, unless coordinated with the release team. And of course, the
time for transitions prior Etch is history.

Frozen Packages
If you are maintainer of a frozen package, please upload only important,
serious, grave and critical bugfixes and localisation or documentation
changes.  Please also inform the release team about any such changes, so
that we can review your package and approve it for Etch.

In cases of doubt, please speak with the release team before uploading - we
definitly prefer questions asked too much over uploads not suitable for

Kernel Status
With the General Resolution about kernel firmware issues, the release team
considers the kernel situation cleared up enough now for release. Please
see our mail to the kernel team [1] for more information.

Release Critical Bug Status
Debian saw lots of Bug Squashing Parties recently - thanks to all
participiants. We made great progress, and are slowly getting back on track
to release in December.

The number of release critical bugs went down a bit to 240 with that -
and the count went up again to about 310 is because we track bugs better
now (please see below). The number of 240 is better than it sounds, as
many long-standing bugs are fixed now - less than 80 bugs are older than
14 days, and about 30 of such bugs are already fixed in unstable.

A long-awaited change is that version tracking has now fully be switched on
on ftp-master, and so bugs fixed in Non-Maintainer Uploads will be properly
marked as done with the correct version. Also, most of the previously
marked "fixed" bugs were closed with the correct version. Though this
increased the bug count by about 40 bugs waiting for transition, this
will help us to not miss any such fix in Etch. For Sarge, we had to
spend major effort quite late in the release cycle on that, for Etch,
this is now easier. (About another 30 bugs are just marked not fixed in
Etch, but are actually, because maintainers edited history, and the
fixing version is no longer part of the changelog - we're just chasing
such bugs and marking them as done with the correct version.)

Release Policy
We have done some last minute adjustments on the release policy. We have
now written down that Etch will be LSB 3.1-compatible - one could actually
expect that for some time now. Another formal change is that we consider
kernel patches that don't apply to the current 2.6-kernels as RC-buggy
another thing we're doing for some time now. We don't consider the
non existence of the required targets in debian/rules as RC, as long as the 
buildds don't have issues - perhaps we want to change that post-Etch though. 
And, the python policy changed a bit in the last half year, so even without
writing it down, that release policy statement isn't current anymore.

As the last two months prior to the release have started, we have started
to treat issues reported late as RC-buggy only for Etch+1 - the same we did
with Sarge. For example, back at that time we got a report in the very last
minute that sendmail had a serious upgrade issue (but without real data
loss). As the release was almost done, we decided to "just" document it
properly in the release notes. We are not yet at that state with Etch, but
as release comes nearer and nearer, we will start to consider more and more
issues reported late as "sorry, reported to late". Of course, real data
loss issues will always be considered RC, as well as some other vital
issues. So, if you know problems, please report them *now*. And, please
still feel free to fix etch-ignored issues, and ask the release team for a
freeze exception/special treatment if the package doesn't make it to Etch
by itself (such issues won't show up on our radar by themself).

So much for now. Thanks to those pulling towards Etch for your steady
work. Let's work together, and let's make a good, stable, high-quality
release of Etch in December.

Debian Release Team

[1] http://lists.debian.org/debian-kernel/2006/10/msg00541.html

Attachment: signature.asc
Description: Digital signature

Reply to: