Release criteria updates: genericizing!

[James Laska]

Thanks for the feedback!  Some follow-up below...

On Thu, 2011-06-23 at 09:12 -0700, Adam Williamson wrote:
> 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 [1] early next week.
> > 
> > https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision
> 
> 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.

Yeah, deleting the CD's for one.  It's technically not needed, but we
have a lot of users that boot a DVD, and install from the online
repositories.  I was trying to articulate that this only applies to
packages from the media.  But perhaps that's redundant after saying
"media-based install"?

> 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?

> 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.  

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?

> 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?

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/f6e7c948/attachment.bin