On Thu, 2011-06-23 at 15:39 -0400, James Laska wrote:
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'.
I was hoping to avoid too much preamble, since for me, the eye really draws to the bullet list, and not the preamble. The deletion was going to be accompanied with my other ideas for secondary architecture handling. But I decided to break that up into two parts, so for now I'll back out that change.
Are we at the point where we need to create a section called 'Assumptions', which would include release-blocking desktops and primary architectures?
Basically, yes: the release criteria are explicitly intended to document the conditions which must be met *for Fedora to release*, and secondary architectures cannot block the release by definition. So we need to call this out *somewhere* on the page. Now you've brought it to the light, I think it actually makes more sense to do this in the preamble than just mentioning it in a couple of the criteria. But it does need to be explicitly mentioned. I think secondary arches can follow the non-blocking desktops model quite nicely, actually: call them out in the preamble and note that breakages of the criteria for secondary arches constitute NTH rather than blocker issues.
The preamble is getting a bit long, though, so we can probably reformat / reflow it a bit to look nicer and more readable.
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?
Good discussion. I was trying to bring the criteria closer to what we actually test (fedora-qa) and maintain (anaconda-devel). Booting the boot.iso with askmethod, then installing from the DVD is a use case that we don't explicitly test and I wasn't intended with the original criteria, and we'd be hard-pressed to get fixes for.
I discussed this use case in #anaconda ... while we don't explicitly prevent a user from doing this, there is no logical use case to do this. They requested rephrasing the criteria to explicitly mention booting, and installing from, the DVD.
Okay, then I agree with the change.
Per request, I'll hold off on filing a bug/patch to restrict CD/DVD askmethod install source selection until the UI redesign settles down.
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.
I like that! Updated draft wiki, however refer to the Final criteria comments below.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
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?
Yeah, you nailed it. I was trying to make it generic, while still specific ... and failed. Without specific examples, I was having a hard time pinpointing the range of devices.
Originally we added this criteria to have a place to hang iSCSI support. I'd include zFCP (s390x fibre channel storage) in the same boat as iSCSI... important, but only critical for the final release.
What if we distinguish between the two Alpha and Final storage device criteria by differentiating between physically attached (Alpha), vs network (iSCSI) or SAN/fibre attached storage (zFCP/qLogic etc...)?
So alpha would be rewritten to cover (PATA, SATA, SCSI, eSATA) ... "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...)"
And final would add in the network component ... "The installer must be able to complete an installation using any networked storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
How's that sound?
Sounds pretty good to me! Nice work.
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.
That's what I was hoping to get clarification on. Is it generally accepted that the phrasing "release repository" means the online +mirrored repos, not the media-based repos?
I dunno, that was just the wording I came up with at the time, I think :) If we can clarify it, that's all to the good.