Debian proposes dropping most architectures

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/msg...
[2] http://lists.debian.org/debian-devel-announce/2004/11/msg...