Fedora: Secondary Architectures Policy
The Goal
To ensure that Fedora can be built for any architecture, in a way that doesn't slow down the development for Fedora's Primary Architectures (x86 and x86_64).
Proposed Policy
(Thanks to TomCallaway for the initial proposal.)
- Architecture Teams. Every secondary architecture must have a team dedicated to managing each arch, led by a lead arch maintainer. (Example: Tom Callaway leads the arch team for sparc.) These arch teams will be empowered to modify any package for the purpose of resolving arch issues, and will be responsible for communicating any such changes to the primary package maintainers.
- Shadow Builds. Secondary arches will not be built directly in the central build system. Instead, when a package is successfully built for a primary arch, "Shadow Builds" would then be triggered (through an as-yet-undefined mechanism) on remote build systems. The biggest upside here: the arch team can use their own hardware to build, and the Fedora infrastructure team doesn't have to worry about maintaining an s390. Note, though, that arch teams should still be making their changes in the upstream Fedora codebase.
- Exclude no arches by default. We should never be setting ExcludeArch, unless the arch teams for the excluded arch sign off on the exclusion.
- Built versus stable. Just because a package builds for a particular arch, that doesn't mean that it actually works. We need the ability to tag a package/arch as "built" or "stable" or "unstable".
- Arch-specific packages. Any arch-specific packages (example: silo for sparc) will be kept in the Fedora repository, and will be ArchExcluded from other architectures as appropriate.
- Using the Fedora name for secondary arches. The basic rule: if all of your arch-based changes are in upstream Fedora, or if the Board declares you to be a special case, then you can call your secondary arch "Fedora". If, however, you maintain your own fork of the codebase and build from that without Board approval, you cannot call it Fedora.
Current Arch Teams
FIXME. Probably start with Spot and the SPARC team. :)
FAQ
Q: Will the secondary arch builds be stored in the fedoraproject.org repositories?
A: Currently the secondary arch builds will be the arch project's responsiblity to host the builds. We can provide pointers to this content from our front page and wiki content.
Q: If the secondary arch builds are not stored in the fedoraproject.org repositories, will links and instructions for enabling external repositories be provided?
A: The front page and wiki can be used to point people to various places. Each Arch could have its own page space for interested parties.
Q: Why can't we host the secondary archs in a special repos/branches on our servers? That might make exchanges between the the main development line and the secondary arches a lot easier.
A: Using a distributed SCM removes the need for their repos to be on our servers. We do not posses the hardware needed to BUILD the packages, so makefiles may need to be modified for different build systems anyway.
Q: How do secondary arch teams get their repositories spun into official Fedora isos for download, and can those be hosted off of fedoraproject.org assuming they follow the guidelines above?
A: We are going to provide the tools we use to spin Fedora isos as opensource software for anybody to use. We'd like to host other arches under the umbrella of Hosted Projects, but currently we do not have the capability of hosting these arch releases.
Q: For PPC, which is currently a primary arch, what will happen to the current rawhide builds? Will they be dropped from the repositories and mirrors? If so when why start with SPARC as PPC is already a primary build for FC6?
A: We've seen decreased interest in the ppc arch, and bugs have languished for multiple releases without anybody even noticing. There is reason to stop doing ppc as a primary arch until (if?) it reaches critical mass once again. We haven't fully discussed what would happen with rawhide builds, but most likely the PPC interest group would need to setup the shadow builds once we have this methodolgy in place. No arches will be dropped until Shadow builds are possible.
Q: What is the criteria for Primary vs Secondary, what is the process for demoting and premoting an architecture. Should we not have these in place before deciding what we're dropping.
A: Currently it is largely a decision made by the Fedora Board taking in much input regarding the use of the platform. No real hard metrics are in place to decide this.
Q: Is this seen as the end of what's going to be done for other arches?
A: No, we want to be able to get further with some of the things from above such as hosting of the actual bits for the architecture builds but trying to wait on getting secondary arches going for that means that much longer until secondary arches can happen. We'd rather get the first bits of infrastructure to make it easier for them to build and be recognized. Then, we'll cross the bridge of hosting. This plan is just the first step, not the only step we want to take.
Action Items
| Task Name | Project Lead | Target Date | Notes |
| Priority 1 | |||
| Document new ExcludeArch rules in packaging committee | TomCallaway | asap | Need to get these policies in, probably by taking them through FESCO. |
| Shadow build kickoff mechanism for secondary arch builds | JesseKeating | new build system | The biggest challenge here is actually writing the mechanism that kicks off shadow builds. Could be as simple as an RSS feed, generated by the central build system, that secondary build systems subscribe to. But since Jesse is going to be driving the new build system, this one is on his plate to figure out, heh. |
| Priority 2 | |||
| Put per-arch package info into package database | tba | someday | Ultimately, we'd like to be able to track arch info in a central database, which won't be possible if ExcludeArch info is kept in individual source files. But this certainly isn't necessary right out of the gate. |
Closed Items
| Task Name | Owner | Completion Date | Notes |
| Wiki page for Arch Policy | GregDeKoenigsberg | 2006-11-13 | Done, obviously :) |