Release criteria updates: genericizing!

[James Laska]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110623/77f836aa/attachment-0001.bin