terminology and the hierarchy of releases

[Will Backman]

Could we develop some hints for basic testers?
Proposed setups?  For example (although this example might be useless):
Testers might want to get two hard drives.  Before testing, tar (or dump,
or pax, or cpio) your system and stick it on the second drive.  Test the
upgrade.  Report bugs to bugzila.  Restore your system to what you had
before.  Wait until next text release, repeat.  This would prevent
upgrades from FC1 -> FC2rc1 -> FC2rc2 ->FC2rc3.  I assume what we really
want is FC1 -> FC2rc1, FC1 ->FC2rc2, FC1 -> FC2rc3

I dunno.  I've never worked in a release testing lab at a software
company, but I would guess there are some common ways to test.  Is there
some sort of grid we can create, and people can test agains and report
against those cases?

>
>>
>> Digging a little deeper, here's what Seth might have been trying to
>> get at (and if not, he'll probably correct me.)  There could
>> potentially be conflicts running the updates/proposed updates code
>> along side the development code.  If nothing else, being subscribed to
>> the proposed updates and the development channels would mean that any
>> testing on the proposed stuff would be invalidated (as you wouldn't
>> really be sure if the failure was the base+updates code, or the
>> bleeding edge development stuff. So, as a good scientist, probably
>> best to sticking with just one changing variable.
>
> Yes, this is what I was trying to say. I running development with the
> other repos enabled makes your tests horribly confusing and not as
> useful for the developers.
>
> -sv
>
>
>
> --
> fedora-test-list mailing list
> fedora-test-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-test-list