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