RFC: Primary architecture promotion requirements

[Matthew Garrett]

This is very much a draft, but I'd like to start a discussion regarding 
what we expect from primary architectures. Feedback not only welcome, 
but actively desired.

-------------------------------------------------------------------------

Secondary architectures in Fedora are subject to looser constraints than 
primary architectures for two primary reasons:

1) To make it easier to bootstrap an architecture without the overhead 
of the primary architecture release engineering process
2) To avoid primary architecture development being held up by poorly 
developed or niche architectures

Promoting an architecture to primary architecture status is a 
significant responsibility. It implies that the port is sufficiently 
mature that little in the way of further architecture-specific changes 
or rebuilds will be required, and also that it has enough development 
effort to avoid it delaying the development of other primary 
architectures. Further, it means that the architecture becomes part of 
the overall Fedora brand. Fedora is an integrated Linux distribution 
rather than a technology collection, and as such there are various 
expectations that the overall Fedora experience will be consistent over 
all primary architectures.

In order to ensure that these expectations are met, secondary 
architectures must meet various criteria before they can be promoted:

1) There must be adequate representation for the architecture on the 
Fedora infrastructure and release engineering teams.
2) All builds must occur on Fedora-maintained build servers.
3) Where technically possible, all supported hardware targets must be 
supported via Anaconda. Exceptions are limited to highly resource 
constrained devices or hardware which provides no means for simultaneous 
support of install and target media.
4) All supported platforms must have kernels built from the Fedora 
kernel SRPM and enabled by default in the spec file. Each kernel must be 
built in a timely manner for every SRPM upload.
5) Sufficient developer resources must be available to fix any 
architecture-specific issues in such a way that they do not delay 
overall Fedora development.
6) It must be possible for maintainers of critical-path hardware 
dependent packages to have direct access to supported hardware in order 
to rectify any release-blocking issues. For example, X maintainers must 
have direct access to any hardware with graphics capabilities.
7) The port must not rely on sourceless binaries unless they fall under 
the generic firmware exemption. Where source and toolchain are 
available, the binaries must be built in the Fedora build 
infrastructure.

As such, promotion to primary architecture status will require agreement 
from the Fedora infrastructure, release engineering, kernel and 
installer teams and is subject to overall approval by the Fedora 
Steering Committee.

-- 
Matthew Garrett | mjg59 at srcf.ucam.org