How to define a release architecture
Ok. I've written this based on the original d-d-a posting from Steve,
and from information cribbed from various other posts. The idea is to
focus consideration on the problems that the release team view as
needing to be solved, rather than just criticising the conclusions
reached.
To start with, here are the original criteria required for an
architecture to be considered releasable, followed by the justification
for each:
FOR AN ARCHITECTURE TO BE RELEASED
* it must first be part of (or at the very least, meet the criteria for)
scc.debian.org (see below)
Sets the base level of technical requirements. If an architecture can't
reach the scc (ports, whatever) requirements, it shouldn't be considered
releasable.
* the release architecture must be publicly available to buy new
Avoids a situation where Debian is keeping an architecture alive. This
isn't intended to result in an architecture being dropped part way
through a release cycle or once it becomes hard to obtain new hardware.
* the release architecture must have N+1 buildds where N is the number
required to keep up with the volume of uploaded packages
This is to ensure that all unstable packages are built in a timely
manner, and that there is adequate redundancy to prevent a single buildd
failure from delaying packages.
* the value of N above must not be > 2
This effectively sets an upper limit on the length of time a single
package may take to build, which helps ensure that doing things like
security fixes for Openoffice doesn't become a problem.
* the release architecture must have successfully compiled 98% of the
archive's source (excluding architecture-specific packages)
A fairly arbitrary figure, but intended to prevent situations where
packages are held back from testing by an architecture not being able to
build them.
* the release architecture must have a working, tested installer
It's not acceptable to release without a working installer, for fairly
obvious reasons.
* the Security Team must be willing to provide long-term support for
the architecture
All releases require security updates, again for obvious reasons.
* the Debian System Administrators (DSA) must be willing to support
debian.org machine(s) of that architecture
This is in order to ensure that developer-accessible machines exist.
* 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
A get out clause - it must be possible for something to be refused if it
would break the release, even if it meets all the other criteria.
* there must be a developer-accessible debian.org machine for the
architecture.
Developers must be able to test their code on a machine running that
architecture.
So, we can effectively rephrase that in terms of a set of basic issues
that need to be addressed:
1) A single architecture must not be allowed to hold back other
architectures by being unable to keep up with building unstable, or
taking too long to build individual packages.
2) The benefit to Debian for supporting the architecture must outweigh
the costs to Debian.
3) Releases must be supportable over the course of a release.
4) It must be possible for developers to be able to test and debug code
on every release architecture.
5) If it would cause other problems, it must be possible to prevent an
otherwise conforming architecture from becoming a release candidate.
6) ? (I /think/ I've covered everything - if there are other fundamental
issues then please add them here)
The Vancouver proposals satisfy all of these, potentially at the cost of
removing some architectures from the set released by Debian. If we want
to avoid that cost, can we come up with another proposal that solves the
same problems in a way that satisfies the release team?
--
Matthew Garrett | mjg59@srcf.ucam.org
Reply to: