> * 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. > What problem does this rule solve ? > * 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. > A far more acceptable alternative would be to not have openoffice on those archs. > * 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. > In which case those packages can simply be not available for the architecture in question. > * 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. > This requirement can be satisfied by stating that some one must be willing to support the security team. > * 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. > This requirement can be satisfied by stating that some one 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 > > 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. > This is unacceptable. It would for example allow archs to be refused because their names starts with an 'A'. > * 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. > > > 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? Yes. See above. Most problems can be solved by other means then just throwing out lots of people's work. Some are actually not a problem but are probably invented to articifially limit the amount of archs. Cheers, Peter (p2).
Attachment:
signature.asc
Description: Digital signature