On Thu, 2011-06-23 at 13:00 -0700, Adam Williamson wrote: > 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. Okay ... I'll ponder and propose if anything draft-worthy surfaces. <snip> > > > 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. Thanks, wiki drafts updated. > > > 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. Is it better/same/worse as follows ... * The final branded release notes from the Documentation team must be present on ISO media and the appropriately versioned generic release notes must be available in the online release repository * A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release package must be available in the online release repository </run-on> Thanks, James
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
