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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
