Testing test releases: do not update

[shmuel siegel]

This thread has been beating around the bush and avoiding even an
attempt to reach agreement. People need to first agree on the purpose of
this testing and the definition of the resources. Even the original
poster seems to have lost track of his original purpose for posting.

To try to put things in their perspective, I think the following terms
need definition, both to what they are and their purpose.

Test Release - is it merely a convenient snapshot for installation but
serving no useful purpose after that (other than PR)? This is what I
would gather from those that advocate that testers stay in sync with
Rawhide.

Rawhide - is it the staging ground for release candidates or is it a
communication point between a developer and those that are in contact
with him? If it is the latter, then there needs to be another repository
that indicates that a package is ready for global testing. If it is the
former, than I wonder why an intermediate stage exists in the Core 1
tree.

I think that Robert Day's initial point is correct. If there is no
stable baseline then testers are constantly finding superficial bugs;
deep bugs that take hours of testing will never get reached. Alan Cox is
also right when he states that a tester should check against the current
state of rawhide before he reports a bug.

I think that a lot of the confusion comes form a lack of a public test
plan and the lack of guidelines for testers. Also, for some reason, the
difference between internal testing (which in the framework of open
source I would consider them to be dedicated testers) and beta testers
(those trying to use the features in a real environment) has been
totally blurred. Most of the arguments against Robert Day were from the
perspective of internal testers. They are right for their function. But
most of them didn't need Test 1 except to test Anaconda; they were in
sync with rawhide anyway. For beta testers, a stable platform is needed.
If they are not at least pretending to do useful work then real life
considerations will never be actualized.

In summary, I also advocate an intermediate repository whose sole
purpose is to keep the baseline usable. If Redhat is unwilling to do
this until development branches to Core 3, then I must assume that
Redhat regards final release of Fedora as the real beta.