-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Mar 2012 19:36:00 -0700 Adam Williamson <awilliam@xxxxxxxxxx> 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. Dennis -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk9qLUMACgkQkSxm47BaWfc4IgCgvlREMiv5Y5ftJC/LR/3OHc8A ax8AnjNrUK4Xl68GD//VECUiH+c1LtNy =CkjD -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
