Release criteria updates: genericizing!
awilliam at redhat.com
Thu Jun 23 16:12:48 UTC 2011
On Thu, 2011-06-23 at 10:46 -0400, James Laska wrote:
> Greetings testers,
> I've been playing with some ideas on how to allow secondary
> architectures to leverage the primary release criteria. I have some
> ideas/challenges that I'll send to the list for feedback later.
> However, in preparation for those ideas/concerns, I'd like to propose
> several changes to the release criteria.
> The proposed changes are intended to make the existing criteria slightly
> more generic, without losing their meaning. Additionally, I've made a
> few other minor changes and added a few questions. Please take a few
> minutes to review the proposed changes (highlighted in red at the links
> below). If nothing alarming surfaces during review, I'll proceed with
> operation genericize  early next week.
I'm unclear on the addition of the word 'package' to 2: what does this
clarify? What is the other type of install if not a 'package install'?
Deleting CD, sure.
On the deletion of the 'primary architectures' mention from 4: we should
probably replace this with something in the preamble, similar to what's
there for 'release-blocking desktops'.
On 7: Not sure about this - I think booting from boot.iso and then using
the DVD as a package source is explicitly supported, isn't it? Was this
criterion meant to ensure that works?
10 seems to kind of fall between two stools, as it's still not very
generic but now it looks a bit like we're supporting very obscure
storage protocols on primary arches. I may be able to come up with
something better here...how about:
"The installer must be able to complete an installation using any
storage interface which is reasonably prevalent in general use" ? That
was kind of the intention of the PATA, SATA, SCSI set for Intel.
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
So for 4 we have the same problem as for Alpha, and it's a bit harder to
re-write generically :/ So, we add iSCSI to the list for Intel, and zFCP
(whatever that is) for another arch; is there anything in particular
about these interfaces that we support? Is it just 'all interfaces for
which anaconda actually has code' at this point?
15 and 17: not entirely sure what the question is here. The Alpha
criterion specifically limits itself to the media, and the generic-*
packages are not included on the media. It is acceptable for packages in
the repository but not on the media to conflict.
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
More information about the test