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 | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
