On Wed, 2013-07-10 at 23:25 -0700, Adam Williamson wrote: > 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. Following today's FESCo decision, I have created a QA trac ticket to co-ordinate this: https://fedorahosted.org/fedora-qa/ticket/393 interested parties please feel free to CC yourselves and contribute any suggested changes / extensions to the above plan there. I'll aim to try and propose some changes as described above for later this week or early next week on test@: that is the list where release criteria revision usually takes place, so please subscribe to that if you're interested in following the process. -- 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
