F20 System Wide Change: ARM as primary Architecture

Adam Williamson awilliam at redhat.com
Tue Jul 9 23:30:43 UTC 2013


On 2013-07-09 6:00, Jaroslav Reznik wrote:
> = Proposed System Wide Change: ARM as primary Architecture =
> https://fedoraproject.org/wiki/Changes/ARM_as_Primary

> The kernel is now a multi platform unified ARMv7 kernel supporting a 
> number of
> SoCs with support expanding with each new upstream release. We build a 
> base
> and LPAE variant similar to i686. There is an ARM specific (ARMv7 and 
> aarch64)
> kernel maintainer working in collaboration with the Fedora kernel team. 
> The
> releases are composed using the exact same tooling as used for the 
> primary
> architectures. Disk images for development boards are generated by 
> appliance-
> creator and the kickstarts live in spin-kickstarts, they take a similar 
> format
> as the livecds on primary but are shipped as an OEM disk image, and 
> like
> primary initial-setup is used to do final user configuration. Like
> primary pungi
> is used to generate an install tree, PXE install trees are created but 
> current
> bootloaders don't support isofs so ISO images aren't currently created.

So, this raises a few questions: with ARM as a primary arch, exactly 
what set of release images would we be supporting? Would we expect to 
test each device-specific image at each release point and verify each 
one of them was correct? Or would we just test a subset and 'trust' that 
the others worked? Do 'we' as a project have access to all the necessary 
hardware for testing each of the images?

(Personally, I have an XO 1.75 and a Trimslice lying around here 
somewhere; I don't know what else anyone else has squirrelled away).

Someone later in the thread asked whether the 'ARM team' would be on the 
hook for QAing the entire kaboodle. Technically with ARM as a primary 
arch it would be QA's responsibility to ensure that whatever images we 
considered part of the 'primary release' were of releasable quality, but 
we are not miracle workers, and we cannot test what we don't have: so 
we'd either need to buy a bunch of test devices or rely on people who 
already have an interest in using ARM and some ARM devices - so, the ARM 
team... - to act under the auspices of the 'QA team'.

I've had an entry on my todo list _forever_ to complete the 
'deliverables SOP' I started several releases ago:

https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables

(I don't really like the current layout, I was planning on revising it)

The addition of a new arch with quite a pile of 'supported images' would 
certainly raise the priority of having such a thing. (We're already 
hitting a problem with our *current* primary arches in this area, 
though, in that the status of the multi-live, multi-arch and 
cloud/appliance images is rather unclear).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net


More information about the devel mailing list