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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
