Quoting Mike McCarty <Mike.McCarty@xxxxxxxxxxxxx>:
I have volunteered some time for test if
I will assume you mean the second part of QA, the "verify" step.
(1) The changes can be "contained" so that they do not compromise
my machine if they fail. IOW, there is a guaranteed backout
which loses no information.
Easiest way to do that is just to run it in a virtual machine.
The only other guaranteed way is to backup your system before
hand, and restore it afterwards, with the needed downtime for
that, or to have a second machine you don't care so much about
to test on.
(2) I have the space on my disc (which is admittedly rather low).
That isn't a problem if you are already running the package, as it
shouldn't increase disk usage much if it all; it is replacing programs
so the space usage is more-or-less the same.
So far, (1) has been a sticking point, I think.
This is a fact of life, and nothing specific to the FL Project.
And it applies to released packages (ala the recent sendmail
debacle) as well as test packages.
In other words, there is little that FL can do to help you meet those
two constraints. Even if we offered a virtual machine test environment,
your lack of disk space would probably prohibit its use.
Now, here is the real kicker:
You can do the first step of QA (publish votes rather than verify votes)
on ANY system and without compromising the system at all. It only involves
comparing the files to other known files, etc. You don't have to install
anything on the system. So, you can help, within your constraints, if
you choose, by doing the first QA step rather than the second.
Mike
--
Eric Rostetter
The Department of Physics
The University of Texas at Austin
Go Longhorns!
--
fedora-legacy-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-legacy-list
