ARM as a primary architecture

Dennis Gilmore dennis at
Wed Mar 21 19:34:22 UTC 2012

Hash: SHA1

On Tue, 20 Mar 2012 19:36:00 -0700
Adam Williamson <awilliam at> wrote:

> On Tue, 2012-03-20 at 13:39 -0400, Peter Jones wrote:
> > >> 4) when milestones occur, arm needs to be just as testible as
> > >> other primary architectures
> > > 
> > > So we have a new hire (hi Paul) who is looking at autoqa, and
> > > we're going to pull together as much as we can here. It would
> > > help me to know (and we're reaching out to QE separately - per my
> > > other mail) what you would consider "testable" to mean, in terms
> > > of what you'd want to see.
> > 
> > I'd largely defer to adamw for specific criteria regarding testing,
> > both in terms of criteria we're testing for (i.e. #3) and in terms
> > of establishing appropriate testing procedures for the platform.
> > I've largely listed those because there's not really any indication
> > in the proposal as it stands that this is well-considered at this
> > point in time.  There's a brief section on how to test, but it
> > appears to be largely pro-forma.
> > 
> > >> 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.
> > > 
> > > So we feel it more appropriate to use image creation tools at this
> > > point, for the 32-bit systems that we have in mind.
> So, my take on this is that if we're to do release validation for ARM,
> at a stage where there is no anaconda-for-ARM and our official ARM
> deployment method is 'download the image file for your hardware and
> flash it' (or however the image file gets written exactly), then we're
> going to wind up with release criteria and validation tests for ARM
> which look very different from what we have for x86.
> I suppose the picture that forms in my mind is that I'd expect
> generation of the images to be fully scripted and automated, and for
> validation to essentially consist of testing that the generated images
> in fact work on each of the 'supported' platforms.

for fedora 18 im planning to move to media-creator, which uses anaconda
to make ec2 and live images.  arm images will basically be the same
type of thing as ec2 images, a raw disk that can be installed onto a
sdcard and booted.  For arm to be a primary arch this has to work, and
has to be supported inside of koji, the same as we do today for x86
lives and ec2 images. there is a small set of the the initial targeted
hardware that could use a traditional anaconda install. most of it can
not. those devices that can can also make use of a live sdcard.  so i
see that as priority 1 for working. with priority 2 being supporting
installs using anaconda and kickstarts. I do not see us making any type
of isos for arm. 

Version: GnuPG v2.0.18 (GNU/Linux)


More information about the devel mailing list