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. -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
