Hello all, As promised earlier on -project[0], after the release team/ftpmaster team meeting-of-minds last weekend, we have some news to share with the rest of the project. First, the news for sarge. As mentioned in the last release team update[1], deploying the testing-security queues has been held up pending some infrastructure enhancements, without which ftp-master.debian.org cannot handle the load of the added wanna-build queues for testing-security. This week, Andreas Barth and Ryan Murray have been applying the finishing touches to allow the needed upgrade of ftp-master.debian.org's openssh to a version that supports connection caching, which is needed before the current ftp-master host will scale to handle the addition of testing-security queues. Once this happens, the testing-security configuration should itself be completed for all architectures in quick succession, with the result that testing-security and testing-proposed-updates will be fully operational in the space of two weeks. This means that we are now (at long last) in the final stretch for sarge's release, and we will be freezing soon once we know that d-i RC3 is golden. While this does not yet give us a timeline with fixed dates for the freeze and the release, this is noteworthy enough in itself that we wanted to share the news immediately. This also means that it's time again to ask maintainers to cut back on uploads of new upstream versions of software, *particularly* of libraries. This hasn't been mentioned in recent release team updates, since it's not very realistic to insist on no new upstream versions for six months without a complete freeze; but as we get close to the freeze it's particularly important to limit churn of library packages, since they tend to delay packages that depend on them -- as has bitten us several times recently. If you believe a library needs updating for sarge, please talk to the release team (debian-release@lists.debian.org) before uploading. The much larger consequence of this meeting, however, has been the crafting of a prospective release plan for etch. The release team and the ftpmasters are mutually agreed that it is not sustainable to continue making coordinated releases for as many architectures as sarge currently contains, let alone for as many new proposed architectures as are waiting in the wings. The reality is that keeping eleven architectures in a releasable state has been a major source of work for the release team, the d-i team, and the kernel team over the past year; not to mention the time spent by the DSA/buildd admins and the security team. It's also not clear how much benefit there is from doing stable releases for all of these architectures, because they aren't necessarily useful to the communities surrounding those ports. Therefore, we're planning on not releasing most of the minor architectures starting with etch. They will be released with sarge, with all that implies (including security support until sarge is archived), but they would no longer be included in testing. This is a very large step, and while we've discussed it fairly thoroughly and think we've got most of the bugs worked out, we'd appreciate hearing any comments you might have. This change has superseded the previous SCC (second-class citizen architecture) plan that had already been proposed to reduce the amount of data Debian mirrors are required to carry; prior to the release of sarge, the ftpmasters plan to bring scc.debian.org on-line and begin making non-release-candidate architectures available from scc.debian.org for unstable. Note that this plan makes no changes to the set of supported release architectures for sarge, but will take effect for testing and unstable immediately after sarge's release with the result that testing will contain a greatly reduced set of architectures, according to the following objective criteria: - it must first be part of (or at the very least, meet the criteria for) scc.debian.org (see below) - the release architecture must be publicly available to buy new - the release architecture must have N+1 buildds where N is the number required to keep up with the volume of uploaded packages - the value of N above must not be > 2 - the release architecture must have successfully compiled 98% of the archive's source (excluding architecture-specific packages) - the release architecture must have a working, tested installer - the Security Team must be willing to provide long-term support for the architecture - the Debian System Administrators (DSA) must be willing to support debian.org machine(s) of that architecture - the Release Team can veto the architecture's inclusion if they have overwhelming concerns regarding the architecture's impact on the release quality or the release cycle length - there must be a developer-accessible debian.org machine for the architecture. We project that applying these rules for etch will reduce the set of candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 and amd64 -- which will be added after sarge's release when mirror space is freed up by moving the other architectures to scc.debian.org). This will drastically reduce the architecture coordination required in testing, giving us a more limber release process and (it is hoped) a much shorter release cycle on the order of 12-18 months. Architectures that are no longer being considered for stable releases are not going to be left out in the cold. The SCC infrastructure is intended as a long-term option for these other architectures, and the ftpmasters also intend to provide porter teams with the option of releasing periodic (or not-so-periodic) per-architecture snapshots of unstable. Also, since the original purpose of the SCC proposal was to reduce the size of the archive that mirrors had to carry, the list of release candidate architectures will be further split, with only the most popular ones distributed via ftp.debian.org itself. The criterion for being distributed from ftp.debian.org (and its mirrors) is roughly: - there must be a sufficient user base to justify inclusion on all mirrors, defined as 10% of downloads over a sampled set of mirrors To be eligible for inclusion in the archive at all, even in the (unstable-only) SCC archive, ftpmasters have specified the following architecture requirements: - the architecture must be freely usable (i.e., without NDAs) - the architecture must be able to run a buildd 24/7 sustained (without crashing) - the architecture must have an actual, running, working buildd - the port must include basic unix functionality, e.g resolving DNS names and firewalling - binary packages must be built from the unmodified Debian source (required, among other reasons, for license compliance) - binaries for the proposed architecture must have been built and signed by official Debian developers - the architecture must have successfully compiled 50% of the archive's source (excluding architecture-specific packages) - 5 developers who will use or work on the port must send in signed requests for its addition - the port must demonstrate that they have at least 50 users These objective requirements would be applied both to the other eight architectures being released with sarge that are not currently regarded as candidates for release with etch, and also to any porter requests asking for new architectures to be added to the archive. This plan has been signed off on by: Steve Langasek (Release Manager) Colin Watson (Release Manager) Andreas Barth (Release Assistant) Joey Hess (Release Assistant) Frank Lichtenheld (Release Assistant) James Troup (ftpmaster) Ryan Murray (ftpmaster) Anthony Towns (ftpmaster) The following people in Debian leadership roles have also expressed their support: Andreas Schuldei (DPL candidate) Angus Lees (DPL candidate) Branden Robinson (DPL candidate) Jonathan Walther (DPL candidate) Again, if you've got any questions, comments or concerns, please raise them on -devel so we can take them into account before putting this plan into effect. Further plans for etch ---------------------- After the release of sarge, the release team will stop tracking the day-to-day status of RC bugs in testing for a while. NMUs for broken packages will be minimal; instead, our RC bug handling will mostly be limited to the usual aggressive removal of broken packages from testing. This will also be a key time for the QA team to focus on deeper quality issues and methods for a change, instead of on individual release-critical bugs. Meanwhile, much of the release team's energy will be focused on coordinating the many major changes that are sure to hit the archive shortly after sarge's release. We already know of a number of major package changes coming up: gcc 4.0, python 2.4, xorg-x11 6.8.2, apt 0.6. If you are planning any other transitions that will affect a lot of packages, please let us know in advance. We will need to complete the larger transitions as fast as possible, to get testing back into a nearly releasable state quickly again after the release. It's also not too early to begin staging complex transitions for etch in experimental, particularly those transitions that will take a while to debug. Post-sarge, we also know that with the new social contract, all documentation needs to adhere to the DFSG. The biggest impact of this change is that documentation that is licensed only under the current version of the GNU Free Documentation License (GFDL) needs to be made available under a license that meets the requirements of the DFSG, or else be moved to non-free. Some maintainers have already opted to move their GFDL documentation to non-free for sarge, but the vast remainder will need to be dealt with soon after sarge's release to keep us on track for etch. Otherwise, it's business as usual for the sarge release. Please bear in mind previous release team updates [1][2] when preparing package uploads to unstable; and if you have any questions, please ask the release team before uploading. Cheers, -- Steve Langasek [vorlon@debian.org] Debian Release Team [0] http://lists.debian.org/debian-project/2005/03/msg00015.html [1] http://lists.debian.org/debian-devel-announce/2005/02/msg00010.html [2] http://lists.debian.org/debian-devel-announce/2004/11/msg00003.html
Attachment:
signature.asc
Description: Digital signature