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 DVDs. You guys (and many others[1][2]) all deserve much more kudos than you get. 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, guys! 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 blockers: - 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 debian-devel) - 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 place. 3. MTAs which do not provide the -bs switch must Conflict: with the lsb package. 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 <http://release.debian.org/etch_rc_policy.txt>. 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 sarge. 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 goodness! -- 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