Release criterion proposal: upgrade methods

[Richard Ryniker]

>I think we could link to
>https://fedoraproject.org/wiki/Upgrading to define
>'supported/recommendation upgrade mechanism'

OK, but to illustrate the problem with indirect references:  the
"Upgrading" page you cite above says to read
  http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/index.html
for details.  This document says (Chapter 20):

  Before upgrading to Fedora 17 you should first bring your current version
  up to date. However, it is not then necessary to upgrade to intermediate
  versions. For example, you can upgrade from Fedora 14 to Fedora 17
  directly.

Therefore, it seems your recent post to this list:
  http://lists.fedoraproject.org/pipermail/test/2012-September/110331.html
may be incorrect.  I think you are right, but the quotation above
contradicts your statement:

  Only 17-18: using the definite article 'the' rather than the indefinite
  article 'a' implies this. It says 'the previous stable Fedora release' -
  which strictly means "only the single preceding release"

My point here is that details in the QA criteria that specify explicitly
what operations must work are valuable.  Indirect references to dynamic
documents (which you properly describe as not owned by QA) mean somebody
else, who may have different interests and objectives than QA and does
not intend to write a QA criterion, defines what your criteria are.

>'official install media' is not quite as obvious; maybe it
>should be a link to the Deliverables SOP when I or someone else finally
>gets that done (my last draft is still at
>https://fedoraproject.org/wiki/User:Adamwill/Draft_releng_SOP_deliverables

Your draft makes no mention of LiveUSB Creator or livecd-tools.  It only
mentions "'dd' or similar tools".  Does this mean persistent storage,
encrypted /home, and other features, are no longer supported on live
media (or perhaps are simply not of concern to QA)?  I gather there has
been a lot of "back and forth" in this area of late - perhaps another
case where explicit language in QA criteria may be valuable, even if it
has to track evolving decisions about what sophisticated live system
features will be "supported".

It is unlikely there will ever be perfect QA criteria, but these criteria
are important: the value of the QA effort depends in significant ways on
their quality.  Whatever their eventual form, I hope my comments help to
make them a little better.