TomCallaway/SecondaryArchitectures

Fedora Secondary Architectures

DRAFT

This document describes how Secondary Architectures should be handled in Fedora.

Author: Tom 'spot' Callaway
Revision: 0.05
Initial Draft: Tuesday May 15, 2007
Last Revised: Tuesday Jul 10, 2007

Purpose

As an open community, Fedora encourages motivated individuals who care about architectures which are currently unsupported. This policy outlines the requirements for how Secondary Architectures can be implemented.

Goals

The goals of this document are as follows:

• Secondary architectures are going to break more often than primary architectures with package churn. By their nature, they get less attention from upstream. We should not fault primary architectures for this.
• Secondary architectures are almost always going to be slower to build than primary architectures. We should not hold up the process for them.
• We should not add any additional burden or workflow change for those packagers who are unable, uninterested, or otherwise unwilling to directly be responsible for secondary architectures. While we strongly encourage packagers to work with the secondary architecture teams to resolve any issues, we should not force packagers to be responsible for all secondary architectures. Many packagers will not have knowledge of these platforms, nor access to the hardware.
• We should not penalize the individuals who are motivated to support secondary architectures.
• We should not diverge from existing policy any more than is absolutely necessary.
• We should leverage the primary architecture builds to catch generic packaging failures. This allows the secondary architecture teams to focus solely on the issues that are specific to their arch. Fixing generic packaging failures is the responsibility of the package maintainer today, so this is also not a change in workflow or responsibility.

Structure

There are two tiers of architectures with Fedora support:

• Primary Architecture: These are architectures with the majority of the users, the most common architectures. Build failures on these architectures are fatal: no packages push to the repositories if they fail to build for a primary architecture. To put it simply: These are the architectures for which Fedora will delay a release if they are not functional. Fedora package maintainers are required to make sure that their package builds properly for this architecture (or is properly ExcludeArch'd).
• Secondary Architecture: These are architectures with motivated Architecture Maintainer Teams, and build hardware. Build failures on secondary architectures are not fatal: if packages successfully build for the primary architectures, they push independently of any secondary architecture build successes or failures.

Architecture Maintainer Teams

In order to manage and support secondary architectures, each secondary architecture will have a team responsible for the Fedora release on that architecture. Each team will assign a team lead, and will be responsible for the following:

• Receiving notifications of secondary arch build successes and failures
• Patching packages cleanly such that they build and function correctly on the secondary architecture, with a minimal amount of architecture conditionalization in the spec file (avoid %ifarch wherever possible). To enable this, architecture team members will have special grouped ACL access to all packages (with some exceptions, such as, glibc, kernel, anaconda), permitting them special access to make changes. This ability requires a great amount of respect, and secondary architecture maintainers are expected to be extremely careful when modifying packages. With special access comes extra responsibility. Think before you commit. Consult the package maintainer before making a change, no matter how trivial.
• Resolving architecture specific bugs filed against packages
• Holding regular status meetings on IRC for the architecture
• Meeting target dates for architecture stability, freezes, release candidates, and releases. If unable to meet target dates, release does not occur. Target dates for secondary architectures will be slightly farther out than the target dates for primary architectures, allowing for longer build times and architecture fixes for packages frozen for primary architectures. If a secondary architecture fails to make release goals for two consecutive Fedora releases, the architecture will be re-evaluated by FESCo.
• Maintaining and hosting the buildserver(s) and storage for that architecture
• Composing trees for that architecture
• Maintain a section on the fedoraproject.org wiki for the architecture, documenting the effort, the maintainer team, the meeting schedule, and other useful information for users, packagers, and developers.
• Deliver progress reports to FESCo on a monthly basis

Each secondary architecture maintainer team will have a dedicated mailing list (e.g. fedora-sparc-list) to serve as a contact point for architecture specific questions, bug notifications, build notifications, etc.

In addition, secondary architecture teams should do the following:

• Run regular 'rebuild all in mock' runs (usually requires dedicated system)

Logistics

Buildsystems

Secondary architectures will need to provide their own hardware, to act as build servers for the koji buildsystem. Neither Red Hat nor the Fedora Project is able to provide hosting space for Secondary architecture systems at this time. Secondary Architecture koji buildsystems need to be accessible via the internet, so that they can communicate with the primary Fedora koji infrastructure.

File Storage

Secondary architectures will need to provide their own file storage. Fedora mirrors can choose whether they wish to mirror secondary architecture trees on an arch-by-arch basis.

Tree Composition

Fedora Release Engineering will not have any responsibility for composing Secondary Architecture trees. Composing trees and install media is the responsibility of the Secondary Architecture team. Each team should expect to have a dedicated server for compose purposes (if possible).

Sandbox Systems

Secondary architecture teams are encouraged to make a "sandbox", or testing system publicly available for Fedora packagers. It is possible to configure a system so that only Fedora Account System users with cvsextras access can ssh into the box, using their FAS credentials.

***TODO*** Document how to set this up.

While sandbox systems are very useful for Fedora packagers who would not normally have access to the hardware architecture, they are not a requirement.

Packaging Issues

Divergence from Primary Architectures

Secondary architecture package trees should be as close to primary architecture package trees as possible. Secondary architectures should not use older versions or customized (hacked up) packages. Secondary architectures may include architecture specific packages where relevant (e.g. bootloaders, xorg drivers). Changes to support secondary architectures must be committed in CVS for each package.

ExcludeArch & ExclusiveArch

Fedora Packages should avoid using ExclusiveArch, except when absolutely correct. Only packages which are exclusively arch specific should use ExclusiveArch (e.g. a bootloader designed for only one architecture). ExcludeArch should only be set when the architecture is not relevant for the package, the package is non-functional on the architecture, or the code does not compile cleanly for the architecture.

By using ExcludeArch on an arch by arch basis, it enables the majority of packages to have the chance to build on new secondary architectures, rather than being immediately ignored by a blanket ExclusiveArch.

Tracker Bugs

Any packager which sets ExcludeArch for an architecture must open a bug against that package, and block that bug against the appropriate ExcludeArch blocker bug.

This will help the Secondary Architecture team track and fix packages for their architecture.

Discussion

Discussion points around this draft can be found here: [TomCallaway/SecondaryArchitecturesDiscussion]