Criterion revision proposal: KDE default applications

[Richard Ryniker]

The defining characteristic of the Live images is that they run
without installation on a user's disks.  Beyond that, they have the
capability to install a minimal Fedora system to a local disk.  Once
the size limit for a live image is increased beyond the capacity of a
CD (or other common media), there seems no reason to limit the live
image size to 1 GB, or any arbitrary value.

Rather than struggle to find what can be be discarded from a live
image in order to achieve a particular size, why not build the DVD
product as a live system, or expand the existing live recipe to
include more of the frequently used packages and not build the DVD?
The DVD installer program has much more flexibility, but this is due
to that arbitrary size limit, I expect: there just is not space for
the full Fedora installation program (plus local repository) in
today's live images.

Others have stated the need for something like the DVD collection of
packages.  Without this, those who need something like it will have to
build their own, obtain it from a third party, or look at another
distribution.  For this reason, to simplify the Fedora products to (1)
network installation and (2) stand-alone installation, I submit the
installation DVD could be built as a live image.

I do not like the thought that many users might decide they have to
copy an entire Fedora repository to a portable hard drive in order to
install the Fedora system they want on a machine without a good
Internet connection.

A sizable group of users may have very limited hardware resources -
no network, only a CD drive.  This group would be a reasonable target
for a "Limited Resources" spin that seeks to tailor Fedora to such an
environment.  For example, these systems may have too little memory to
support anaconda (and many of the applications in Fedora's default
configuration).  Maybe a new SIG for this target.  (Perhaps it already
exists and I, with richer hardware resources, never looked for it.)

In any case, Adam Williamson's articulate comment about the practical
limits to what Quality Assurance can achieve with a six month release
cycle and the available resources is very relevant.  The release criteria,
in part, seek to define what will be tested, but they read more like a
prescription for what "should" be tested.  Modifications to limit and
make more specific the actual test coverage can help Fedora users
better understand what they have, and reflect the reality of QA
resource limits.

To this end, it would be good to have better distinction between what
QA tests and what other groups - SIG, upstream, packager, spin
creator, architecture group, etc. - are responsible to test.  QA test
criteria is one place to document this, at least the QA view of it.

Adam, your recent work on storage tests reads like a Unit Test Plan
for anaconda: something that tries to exercise all the code paths of
the program.  Is this the proper function of Fedora QA?  If it is,
what is the proper fraction of the anaconda development budget
to be allocated to Fedora QA for this purpose?

I use this as an example to support your observation that QA clearly
does not have resources to test all it might want to test, and clearer
definition is required for what QA will test and what others have to
test.  Your storage test cases look like something anaconda developers
should run before they let a new version loose.

Throw away a package because it was not tested, failed a test, or
missed a deadline is not a solution, however vexed one might be about
what has not been done.  It is natural that many changes will occur in
Fedora's package roster.  I counted 39,500 rpm files in the F20
repository.  Lots of changes, for many reasons, are normal, but it
is not sensible to expect all these parts to work properly.  It is
not even reasonable to expect the ten percent of these files on the
DVD to all work properly.

Fedora QA, as a group, should probably take a pragmatic approach and
focus on "critical path" and installation issues that affect large
groups of users, and refer more detailed tests to others.  Do more,
certainly, if resources permit.  And try to influence others to be
more aware and effective in their test activities.