|
|
| (One intermediate revision by one other user not shown) |
| Line 1: |
Line 1: |
| {{draft}}
| | This page has moved to https://fedoraproject.org/w/index.php?title=Secondary_Architecture_Promotion_Requirements |
| | |
| Secondary architectures in Fedora are subject to looser constraints than
| |
| primary architectures for two primary reasons:
| |
| | |
| * To make it easier to bootstrap an architecture without the overhead of the primary architecture release engineering process
| |
| * 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:
| |
| | |
| # The Fedora infrastructure and release engineering teams must indicate an ability and willingness to support the port.
| |
| # All builds must occur on Fedora-maintained build servers.
| |
| # Where technically possible, all supported hardware targets must be capable of installation using Anaconda. Exceptions are limited to highly resource constrained devices or hardware which provides no means for install and target media to be simultaneously accessible.
| |
| # 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.
| |
| # Sufficient developer resources must be available to fix any architecture-specific issues in such a way that they do not delay overall Fedora development.
| |
| # 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.
| |
| # 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.
| |
| # Excludearch may be used only to disable packages that are fundamentally architecture specific or which contain unported architecture-specific code.
| |
| # Installable, testable images must be generated at the normal project milestones in a way that conforms to release engineering and QE requirements. Where possible, image generation should be integrated into the existing image generation infrastructure.
| |
| # The port should work with the documentation and website teams to determine the work needed to add the architecture. Resources should be available to assist those teams in adding the architecture to public resources.
| |
| # The architecture must be included in and meet appropriate formal release criteria
| |
| | |
| This list is not intended to be exhaustive - 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 Engineering Steering Committee, and additional criteria may be imposed if felt to be necessary.
| |
