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