RFC: Primary architecture promotion requirements

[Kevin Kofler]

Matthew Garrett wrote:
> 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.

So, first of all, I disagree that there should be a process for promoting an 
architecture to primary in the first place. The set of primary architectures 
(x86_64, i686) should be set in stone unless a MAJOR change in hardware 
landscape happens, e.g. x86 gets discontinued by the hardware manufacturers 
and everyone uses ARM instead. I don't see that happening any time soon. 
Adding primary architectures puts a major burden on all Fedora maintainers.

In the current state of things, I don't see a sufficient demand for making 
ARM (or even less any other secondary architecture) a primary architecture. 
If ARM is really the future as its proponents claim, we can revisit that in 
a few years. Not now.

The focus should be on finding ways to make secondary architecture releases 
more timely (i.e. it's not acceptable that e.g. the stable ARM release is 
still Fedora 14 which doesn't even get security updates anymore), not to 
cheat around the problem by making ARM a primary architecture (which does 
not help all the other secondary architectures).

> 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

3) To avoid slowing down all builds by having to wait for the slow builders 
to complete them.
4) To avoid build failures caused by platform-specific toolchain bugs or 
limitations failing the entire build and forcing the maintainer to fix them.

> 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.

Why would we want to make such an architecture (the "exceptions") primary?!

> 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.

This lacks several important requirements:
* The platform should actually have a significant market share. Why would we 
want to make an obscure niche device a primary architecture (even if it 
fulfills all the 7 requirements you listed)? Your criteria would even allow 
architectures to become primary which don't have anywhere near the market 
share even ARM has (let alone x86).
* The builders should not take significantly longer to complete builds than 
the x86 builders. Otherwise builds (especially chain builds) will be slowed 
down by a lot.
* The architecture needs to have sufficient support from the pool of Fedora 
maintainers as a whole, who will be on the hook for making their packages 
build for it.
* The toolchain (port) needs to have sufficient quality to not cause tons of 
platform-specific bugs which are of no fault of the package. (We've had our 
fair share of those with ppc/ppc64, due to both bugs and bizarre TOC size 
limitations.)

        Kevin Kofler