F20 System Wide Change: ARM as primary Architecture

[Adam Williamson]

On Wed, 2013-07-10 at 23:18 -0700, Brendan Conoboy wrote:
> On 07/10/2013 10:12 PM, Adam Williamson wrote:
> > As I said elsewhere in the thread, the criteria should be subsidiary to
> > the primary arch designation. If we decide we want to take ARM as a
> > primary arch in any form in which the current release criteria don't
> > apply, we should amend the release criteria.
> >
> > In context I was just providing some background information: as the
> > criteria currently stand, KDE and GNOME are the release blocking
> > desktops. (Technically that in itself isn't really an aspect of the
> > release criteria; it's Fedora status quo that predates the current form
> > of the release validation process).
> 
> Yeah, it seems like a foregone conclusion that release criteria would 
> need to be modified.  I don't think the current proposal includes this, 
> but perhaps it should.  Realistically what's going to be needed is some 
> form of granularity on "primary".  At first blush I like the idea of a 
> "primary server" and "primary desktop" designation (maintaining a 
> unified build system) but haven't thought the full consequences through.

The required change is not, in fact, necessarily that dramatic, as I
mentioned earlier in the thread. As written, the release criteria do not
explicitly require that the release-blocking desktops work on all
primary architectures. They just talk about things that are required to
work within the desktops themselves.

What would actually need to change for ARM, I think, are just the very
early criteria and preamble, where we have this stuff:

"The term 'release-blocking images' means all the images in which bugs
are currently considered capable of blocking a Fedora release. The
current set of release-blocking images includes the network install
image, the DVD image, and the live images for each of the
release-blocking desktops."

"All release-blocking images must boot in their supported
configurations.", with a bunch of footnotes about what that means
precisely.

I think we could make relatively minor tweaks to those bits - obviously,
we would extend the list of 'release-blocking images', which functions
as a very concise 'deliverables' list - and maybe make it a bit clearer
in the footnotes to the 'initialization requirements' criteria exactly
what behaviour is required from those images. That would really be all
that would be necessary, I think. We _could_ explain specifically in the
preamble that certain criteria are not relevant to certain arches, if we
wanted to.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net