While Debian have release criteria for packages, up until now they didn't have any for the architectures. Andreas Barth has announced the new release criterias.
It has been discussed for a while already. While we have release
criteria for packages, up until now we don't have any for the
architectures. However, decisions made about an architecture affect
both our users (and developers) and the release cycle much more than
decisions about an individual package.
For that reason, we discussed in multiple meetings, together with porters,
ftp-masters and other people more than once how the criteria should
look. Also, there was more than one discussion on debian-devel. [1, 2]
In essence, the requirements that are being established exist to ensure
that the port is in good enough shape and sufficiently well-supported
* our users will benefit from the architecture's presence in a
* the architecture will give our users the same support and
stability as any other architecture in the stable release,
* the architecture's inclusion doesn't negatively impact other
architectures or the release process as a whole.
These criteria do _not_ control addition of an architecture to unstable,
but rather apply to architectures which the ftp-masters have accepted
into unstable and are targetting testing and the next stable release.
In other words, an architecture that fails these criteria can still be
part of unstable. And, of course as always, the release team can grant
exceptions – which is of course an exception, and we need to be
convinced that this is the right action.
Over the next two months, all of the current release architectures will
need to requalify for inclusion in etch according to the following
criteria. See the bottom of this mail for details.
Now, looking more into details, the criteria are:
| * Availability:
| The architecture needs to be available for everybody, i.e.
The reason for this should be obvious
| it must be available without NDAs and
Same for this. We're about free software.
| it must be possible to buy machines on the market.
The reason should be obvious: Our users should be able to use the
Of course, it is known that there will be some timespan where a product
line is end-of-lifed by its hardware manufacturer, but still useful to
users (and still possible to buy the product). So, we also don't directly
drop the architecture on the floor, but on the other hand, there will be a
day where the port's porters and Debian cannot longer give the port that
much support that we can do stable releases with it – and even a day when
we cannot longer support that port at all.
| * Developer availability: The architecture must have a
| developer-available (i.e. debian.org) machine that contains the
| usual development chroots (at least stable, testing, unstable).
This criterion is there so that any developer can actually find out what the
issue is if his package fails to work on a specific architecture. Of
course, when adding a new architecture, there will be a time without a
stable release, and there will be some special arrangement how such a
machine can be provided without having even some packages in testing. But
that's not meant as a no-go, as long as we are quite optimistic that adding
the new machine will actually work in time.
| * Users: The architecture needs to prove that developers and users
| are actually using it. Five Developers needs to certify in that
| they're actively developing on this architecture, and it needs to
| be demonstrated that at least 50 users are using the platform. We
| are counting users, not machines; e.g., one s390-installation
| with 50,000 users fullfils the user criterion just fine.
As already discussed multiple times, the “50 users” really means “50
individuals using that architecture”. Both criteria are there to make
sure that an architecture gets just enough usage so that
architecture-specific bugs are found in time.
| * Installer: The architecture must have a working, tested installer.
Obviously, we need an installer. Though that doesn't say “debian
installer”, we think that our users expect that there are not too many
different ways for them to install the released version of Debian etch one
| * Porters and Upstream support: There is support by the porters and
| upstream. This is especially true for the toolchain and the
Obviously, we cannot keep a port alive if there is nobody doing support for
it. Of course, it is quite possible that Debian and upstream support is
done by the same persons. And our experiences with support of gcc-4.0
on m68k have shown that it is possible to get such issues fixed, if the
porters are notified in time and are really interested in their port (and
if there are enough porters).
| * Archive coverage: The architecture needs to have successfully
| compiled the current version of the overwhelming part of the
| archive, excluding architecture-specific packages.
Our back-of-the-envelope number for this criterion is 98%. As pointed
out multiple times during recent discussions, 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 optional/extra packages with severe portability issues, but
porters must take responsibility for working with maintainers to fix
| * Archive cleanliness: All binary packages need to be built from
| unmodified sources (i.e. from the source found in the
| ftp archive), and all binary packages need to be built by Debian
That's already part of the normal rules. Just repeated for clearness
| * Autobuilder support:
| The architecture is able to keep up with unstable
This is obviously needed. If the architecture cannot keep up, there is no
way to support it in a stable release.
| with not more than two buildds,
That is one of the most discussed criteria. As mentioned previously ,
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.
When reviewing the past however, m68k as the architecture with the most
autobuilders isn't performing too bad regarding the availability of the
autobuilders. So, there is the chance for m68k to get grandfathered in
for this clause. However, we expect that they explain why the higher
numbers of buildds they use are not as bad increasing the maintenance
| has redundancy in the autobuilder network,
This is the “it needs to have N+1 buildds” – just in case some buildd has
hardware failures or whatever else. History told the release team that
redundancy is really necessary. No one in the release team wants to be
in the position of tracking where a box in Europe is just located, and
proding some developer in that country to pick the box up, because that
box has become the largest blocker of the next stable release.
| keeps their autobuilders running for 24×7,
Of course, autobuilders can have hardware maintainence. But the
autobuilders need to be able to run 24×7, and the need to be generally
up all the time (and thanks to the redundancy above, there should always
be an autobuilder currently running).
| has autobuilders acceptable for security support.
If we want to do security support, that of course needs to be there.
| * Veto powers: Security team, system administrators and release team
| must not veto inclusion.
This is also a much discussed criterion. But – though it is never intended
to be used, there is basically no way how we can make it without it.
Please see the previous mail  for further reasonings. Of course, before
the veto power is used, the relevant team needs to send a mail to the
developers at large and to the porters and explain what concerns they
raise, and only if the concerns are not addressed appropriate after
reasonable time, the veto power can be used.
So, of course the question is: Which of the current architectures do
fulfill this set of requirements? To get this answer, and because we
know there are currently architectures which do *not* meet the
requirements, all architectures will need to be requalified.
Porters, please feel free to prove us compliance of your architecture with
the remaining issues (that are all as of today – or rather, please start
on this, as this needs to be done soon. We will follow up when we made some
progress, so that you all see what parts and architectures are more
problematic before any decision is done. We hope to finish this in the
next two months.
And of course, as always: If there are any issues that you think aren't
addressed properly, please feel free to contact
firstname.lastname@example.org – but remember: that address is not a
discussion list, so if you rather want to discuss, select a more
appropriate place for that.