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

Bits from the release team: the plans for etch

So I guess that taking four months for the release team to comment on
the release of sarge makes the sarge release itself seem timely and
efficient... right?  (Of course right.)

Since I already blogged a round of thanks[0] back in June which many of
you have likely already read, I don't intend to repeat myself here.
Instead, I find myself echoing Anthony Towns's announcement of the woody
release, taking this opportunity to single out a few familiar names of
those people who went the extra mile/kilometer/furlong to not just make
Debian a great system, but to also make the sarge release possible.

On behalf of the Debian release team, therefore, I'd like to thank
Anthony Towns himself, both for his efforts in steering sarge the first
90% of the way, and for his patient help whenever we managed to break
the testing software during the second 90% of the way; and Ryan Murray
and James Troup, for their tireless (or at least endless...) work to
keep the ftp-master and autobuilder infrastructure afloat, and also for
that extra-special symlink change at the end which, for reasons that are
a mystery to me, requires two days of hard labor to achieve. ;)

Also deserving of mention are Jeroen van Wolffelaar and Joerg Jaspert,
for the thorough "spring cleaning" they gave the archive prior to
release; Joey Hess, for wrestling that microcosm of the Debian release
process, our installer; Rob Bradford and Frans Pop, our release notes
editors; and Steve McIntyre and Mattias Wadenstein, who successfully
carried cdimage.debian.org forward into this era of numbered Debian

You guys (and many others[1][2]) all deserve much more kudos than you

Finally, a big thank you to to the rest of our release team who helped
make sarge possible:  Colin Watson, Andreas Barth, and Frank
Lichtenheld.  I'm not sure any of us knew what we were signing up for,
but it's definitely been a blast.  We should do this again some time,

We Should Do This Again Some Time
While everyone else was revelling in the newfound freedom to break
unstable *HARD* these past few months, the release team has been busy
plotting how best to spoil your fun by bringing testing back into line
for another release.  We had a release team meeting back in June to
discuss plans for etch, and have set a target date for the release in
December 2006.  This is the timeline that we think will get us there:

N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
                        e.g. cdbs)
N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
                        freeze, d-i RC]
N      = Mon  4 Dec 06: release [1.5 months for the general freeze]

We believe that one key to meeting these deadlines is letting
maintainers know about them well in advance so that they can plan
accordingly, so -- here we are.

The base-freeze used for sarge served its purpose, though for obvious
reasons we would like the base freeze for etch to not be quite so long.
This gives us the beginning of the freeze at the end of July 2006,
starting with the essential toolchain and the kernels; followed a week
later by other toolchain packages and the full base system, and
immediately afterwards the publishing of what we hope will be the final
installer release candidate.

The general freeze will follow in October 2006, lasting roughly as long
as the sarge freeze did.

What's not spelled out in the above timeline is that this basically
leaves people until around the end of the year to to implement any
dastardly plans they have that require sweeping changes to the archive,
followed by another half a year of comparatively minor changes (you
know, the kind that *don't* render half the libraries RC-buggy in a
single upload... <cough>C++ ABIs</cough>), and then the freeze begins.
While this may not sound like a lot of time for feature innovation, you
may get an inkling of our rationale by looking at the release-critical
bug count for etch[3]:  in spite of many package removals from testing,
the RC count for etch has been above 400 pretty consistently since the
change to gcc 4.0, which is more than the highest recorded RC bug count
during the sarge release cycle.  It will take a concerted effort to get
this bug count under control in the specified time frame, so please help
-- the sooner people get involved with squashing RC bugs (via BSPs,
NMUs, etc.), the better.

Release blockers
Of course, another key to planning a timely release is identifying those
issues that can hold up the release and working to address them early.
In addition to the umbrella category of "release-critical bugs", we have
put together a very short list of those issues which we consider release

 - gcc 3.3 -> 4.0 toolchain transition
 - xfree86 -> xorg transition
 - amd64 as an official arch (and the mirror split as a pre-condition
   for that)
 - sorting out docs-in-main vs. the DFSG
 - sorting out non-free firmware
 - secure apt

This naturally doesn't mean that these are the *only* things we'd like
to see happen for etch, but these are the only major issues we see that
would justify delaying the etch release.  If your pet project isn't on
this list, please plan to have your changes completed before next
October. :)

As many users of testing can attest, the xorg transition is already
completed; and there have been sightings of both secure apt and the
glibc/gcc transition in unstable.  So we are pretty optimistic that none
of the release blockers will prevent us from meeting our target release
date, but of course we need more than optimism to accomplish a release.
If you are a maintainer of a package affected by one of these issues,
please do your part to help us keep on schedule.

Frank Lichtenheld has already posted an announcement[4] detailing the
release team's plans for the question of non-DFSG documentation in main.
Naturally, none of us are thrilled at the prospect of releasing etch
with much of its documentation removed from main.  We are still hopeful
that discussions over both the GFDL and the Creative Commons licenses
will bear fruit, but with the mandate from last year's GR to bring all
contents in line with the DFSG, it is not realistic to defer these
changes indefinitely if we want to release etch next year.  We certainly
would prefer documentation rewrites to documentation removals, though,
and would welcome volunteers willing to coordinate work on authoring
replacement documentation.

Pet release goals
There are a number of other systematic improvements on the drawing board
for etch which we consider worthwhile even if we don't consider them
blockers.  We would like as many of these goals as possible to be met
for etch, but by definition they are not release-critical.  There is
a chance that some of these goals may become release blockers for
etch+1, though.

The "pet release goals" that we are aware of are:

- finishing the /usr/doc -> /usr/share/doc transition
- comprehensive SELinux support by building everything with libselinux
- pervasive LFS (large files) support
- dependency-based init
- UTF-8 locales by default
- symbol versioning in libraries where it's needed
- rethinking how we handle lib dependencies (see discussion on
- a true system locale that doesn't depend on the /etc/environment
  config file, in order to support localized boot processes
- ensuring that all binary packages in the archive are listed in the
  source package's .dsc
- fixing udeb sync issues and testing migration
- kernel: not more than 2 versions; 1 source package for all archs
- getting rid of circular deps (in the general case; there are corner
  cases in essential)
- multiarch support, to cure us of special-cased packages and source
  duplication for architectures like amd64 and ppc64

Please consider helping us meet these goals, not only in your own
packages, but also in others' through patches and NMUs.

Updates to the release policy
In addition to the systematic changes planned for etch, there are a few
changes to the release policy itself which are grounds for excluding a
package from the release.  Some of these may look familiar:

1. All content in main and contrib must meet the DFSG

2. The clean, build*, and binary* targets of packages must not change
   the build-dependencies or the changelog when called.
   During the course of the sarge release, we found a number of packages
   that were automatically editing changelogs and/or package build
   dependencies in one of the standard targets.  We believe that these
   are violations of current Debian policy, but more importantly from a
   release standpoint, they *break* things.  Having convenience make
   targets for such updates is fine, but using the standard debian/rules
   targets *as* the convenience targets is not.  At one point or another
   doing this will definitely result in release-critical breakage of the
   package -- the best way to avoid that is to not do it in the first

3. MTAs which do not provide the -bs switch must Conflict: with the lsb

   This was already a de facto exception granted for sarge, which has
   now been formalized.

We hope to also move to LSB 3.0 compatibility, but more discussion with
the Debian LSB team is needed for this to happen.  In addition, the
sarge experience has raised concerns with the current Python policy, but
that is an area which will require ongoing work together with the Python
team in order to effect a change, rather than pronouncements from the
release team...

At all times, the full etch release policy can be found at

Release team musical chairs
In addition to changes to the release *policy*, there are a couple of
changes to the release *team* to announce.  As Colin Watson has already
announced[5], he has decided to step down as my co-Release Manager for
etch.  Colin, thanks for all you've done; it was great working with you
for sarge, and just because your title will say "Release Assistant"
instead of "Release Manager" now doesn't mean we plan to let you off the
hook completely for etch. ;)

On the other side, that leaves a vacant Release Manager seat which the
team is agreed should be filled, and Andreas Barth has risen to this
challenge.  Please welcome Andreas as my new co-RM for etch -- anything
you would pester me about, you should now feel free to pester him about
instead. >:)

Issues for the release notes
We would like to encourage people to submit content for the etch release
notes throughout the development cycle, so that upgrade concerns can be
documented when the changes are fresh in people's minds.  To help with
that, there is now a release-notes pseudopackage at bugs.debian.org.
Please use it.

NMU policy
After lots of experimentation with NMU policies during the sarge release
process, it's pretty clear that permissive NMU policies had a HUGE,
positive impact on our ability as a project to cope with outstanding
release-critical issues.  We don't want that to stop now just because
the sarge release is behind us; NMUs don't just speed up the release,
they're also great for helping the quality of Debian!  For this reason,
we would like to continue the 0-day NMU policy from sarge throughout the
etch release cycle.  But first, we'd like to hear from you, the
developers, about what *you* thought did and didn't work with NMUs for

So after a brief respite following the sarge release, we're ready to
move etch into full swing.  Look forward to more of these emails from
the release team periodically from here on out, chock-full of release-y

Steve Langasek                                     [vorlon@debian.org]
Debian Release Team

[0] http://www.advogato.org/person/vorlon/diary.html?start=10
[1] http://www.debian.org/intro/organization
[2] http://www.debian.org/devel/people
[3] http://bugs.debian.org/release-critical/
[4] http://lists.debian.org/debian-devel-announce/2005/09/msg00007.html
[5] http://lists.debian.org/debian-project/2005/09/msg00199.html

Attachment: signature.asc
Description: Digital signature

Reply to: