ARM as a primary architecture
pjones at redhat.com
Tue Mar 20 15:52:29 UTC 2012
In yesterday's FESCo meeting I told you I'd make a list of specific issues
I have with the current proposal for ARM as a primary archictecture. There
are some places where I think the current proposal fails to deal with some
necessary aspects of becoming a primary architecture, and some places where
I don't think the approach is quite right. So without further ado:
1) mechanisms need to be in place to get package maintainers access to fix
arm-specific bugs in their packages
2) excludearch is not an option. This is fundamentally contrary to being
a primary arch. In fact this is one of the defining characteristics of
a secondary arch.
3) arm must be integrated to the formal release criteria
4) when milestones occur, arm needs to be just as testible as other
5) installation methods must be in place. I'm not saying it has to be
using the same model as x86, but when we get to beta, if it can't be
installed, it can't meet similar release criteria to existing or prior
primary arches. Where possible, we should be using anaconda for
installation, though I'd be open to looking at using it to build installed
images for machines with severe resource constraints.
6) supported platforms must be fully integrated into building and
installation. If you need a special build procedure to make this happen
for kernel, we need to have rel-eng signing off saying they've approved
of whatever method that is, and QE signing off that they think it'll
result in a something they can claim is tested enough to release as a
7) it can't be a serious maintenance burdon due to build related issues.
We need a couple of groups to sign off that builds are fast enough, not
just on a "full distro rebuild" (throughput) level, but also on a
"doesn't destroy my workflow due to waiting on it" (latency) level.
Obviously any feedback you guys have on this is welcome.
Old MacDonald had an agricultural real-estate tax abatement.
More information about the devel