This is the canonical list of criteria for an architecture to be considered as a candidate release architecture. This only affects architectures already in unstable; the criteria for an architecture to be considered for unstable are set by the ftp-masters and are not covered by this document. Text marked in italic is considered as additional explanations and for border-line cases.
Exceptions for individual points on this list may be given to an existing architecture by the release team if justification is provided.
In essence, these requirements exist to ensure that the port is in good enough shape and sufficiently well-supported that
These criteria are:
There will be some time while an architecture goes to end-of-life where it will not be easily buyable anymore at the market, but it is still useful for Debian's users if we continue support. This criterion doesn't mean it should be directly dropped, but there will be also a time where Debian and the port's porters can't really support the architecture anymore, and it reaches its natural end-of-life. (In other words, we are stricter with adding a new architecture, than at determing whether to keep an existing architecture.)
We are counting users for the second criteria, not machines; e.g., one s390-installation with 50,000 users fullfils the user criterion just fine.
This criterion doesn't forbid that Debian's and upstream's support is handled by the same persons.
Our back-of-the-envelope number is 98% of the archive. We don't have a good way to measure an architecture's compliance with this yet, but we'll work on figuring that out; of course we will exclude hardware-specific packages and buggy packages with severe portability issues in optional/extra packages, but porters must take responsibility for working with maintainers to fix portability issues.
That's just what's always true. Here only for completness.
We need of course autobuilders, and they need to be able to keep up.
As mentioned multiple times, there is a nontrivial cost to each buildd, which increases super-linearly; there have been cases in the past where this resulted in ports with many autobuilders slacking when updates were necessary.
Redundancy is necessary just in case some buildd has hardware failures or whatever else. History told the release team that redundancy is really necessary. Noone in the release team wants again to track where a box in europe is just located, and prod some developer in that country to pick the box up, because that's largest blocker of the next stable release.
Of course, autobuilders can have hardware maintainence. But the autobuilers need to be able to run 24x7, and the need to be generally up all the time (and thanks to the redundancy above, there should always be an autobuilder currently running).
The release team will give any port multiple warnings with verbose explanaition, if the ports starts to fail any of these criteria, before taking any action.