jwb: While I understand that armv5tel and armv7l are the same CPU arch with different ABIs, I think it's more important to be clear about what is being added and the costs. The more data you provide, the less questions will be asked and I can guarantee this question is going to come up. If you look at arm.koji.fedoraproject.org you'll see that armv5tel and armv7hl are essentially "arches" in Fedora terms. So that's two more builds per-package. Add in ARM64 and now you're up to 3. If another x86 ABI (e.g. x32 or truly building for i386/i586 in addition to the i686 we do today) were proposed, it would most likely be added as a secondary "arch" rather than just lumping it in with the existing primary x86 builds.

jwb: While I understand that armv5tel and armv7l are the same CPU arch with different ABIs, I think it's more important to be clear about what is being added and the costs. The more data you provide, the less questions will be asked and I can guarantee this question is going to come up. If you look at arm.koji.fedoraproject.org you'll see that armv5tel and armv7hl are essentially "arches" in Fedora terms. So that's two more builds per-package. Add in ARM64 and now you're up to 3. If another x86 ABI (e.g. x32 or truly building for i386/i586 in addition to the i686 we do today) were proposed, it would most likely be added as a secondary "arch" rather than just lumping it in with the existing primary x86 builds.

+

+

blc: I've added a Q&A for v5 vs v7. You're right that people are going to ask so this is included to provide an answer before it become an issue.

2) The question about slowing down builds has a misleading answer. It focuses on mass rebuild, however builds for

2) The question about slowing down builds has a misleading answer. It focuses on mass rebuild, however builds for

Latest revision as of 21:40, 29 February 2012

A few comments/questions:

1) Which particular ARM subarchitectures are being proposed for promotion? Currently there is:

* armv5tel
* armv7l
* armv7hl

and soon 64-bit ARM.

blc: There is currently armv5tel and armv7hl (No armv7l). We don't want this proposal evaluated on a per-ABI basis if possible. Think of arm as x86- we're just doing a couple different ABIs.

jwb: While I understand that armv5tel and armv7l are the same CPU arch with different ABIs, I think it's more important to be clear about what is being added and the costs. The more data you provide, the less questions will be asked and I can guarantee this question is going to come up. If you look at arm.koji.fedoraproject.org you'll see that armv5tel and armv7hl are essentially "arches" in Fedora terms. So that's two more builds per-package. Add in ARM64 and now you're up to 3. If another x86 ABI (e.g. x32 or truly building for i386/i586 in addition to the i686 we do today) were proposed, it would most likely be added as a secondary "arch" rather than just lumping it in with the existing primary x86 builds.

blc: I've added a Q&A for v5 vs v7. You're right that people are going to ask so this is included to provide an answer before it become an issue.

2) The question about slowing down builds has a misleading answer. It focuses on mass rebuild, however builds for
individual packages _will_ slow down because more builders doesn't really help on a per-package basis. E.g. if you're building for i386, x86_64, arm5, arm7, and arm64 (arm8?) then you'll now be waiting for 3 additional arch builds to complete on a per-package basis. Even with enterprise class ARM servers running at 1-1.6GHz, the individual ARM builds are likely going to be slower than the x86 builds. I would suggest either changing the answer to reflect that, or provide data (once available) showing that build times for the ARM builds are comparable to x86. This is important because one of the main detractions of PowerPC was the much slower per-package build time that held everything up.

blc: We will provide data once available. The average build should take a similar amount of time on the hardware we anticipate using.

3) I would suggest adding a hypothetical question along the lines of "If an ARM build fails for my package, does it fail the entire build until it is fixed when ARM is a primary arch?" The answer should of course be yes.