Testing test releases: do not update

[Gerry Tool]

Jason Knight wrote:

> I couldn't thave said it better myself, I believe this is a simple 
> case of a little effort now a whole lot less effort later. This would 
> make much more sense.
>
> Robert P. J. Day wrote:
>
>> and for those who think it's too much work for red hat to do it this 
>> way,
>> i submit that it's exactly the opposite.  when there's a test release 
>> out in the wild, red hat should be spending their time dealing with 
>> bug reports that represent things that are just flat out *broken*.  
>> not stuff from rawhide, not RFEs, not wish lists.  they should be 
>> focused on fixing stuff that's broken, and that means restricting 
>> their attention to just those things so that the testers' time is 
>> well spent.  and that means not having to deal with rawhide.  there 
>> should be a *separate* update channel purely for fixing broken 
>> things.  and, no, i don't care if it takes red hat a few more minutes 
>> to set this up.  it's not about *them*, it's about making the 
>> testers' time as productive as possible.  but wait, there's more.
>>
>>  
>>
> This would be excellent as well, maybe this would be taken under the 
> wing of the documentation project?
>
>> anyway, what would be nice is if there was a real and comprehensive 
>> document for testers, explaining how releases work, how to query 
>> bugs, how to report bugs and so on.  and by "comprehensive", i mean 
>> something a little more meaty than "file bugs at bugzilla against 
>> your current release." 
>> i'm convinced that the testing procedure deserves an update repo, and 
>> i'm just as convinced that that repo shouldn't be rawhide.
>>  
>>
I heartily agree with this.  The uncoordinated mixture of rawhide 
packages, fixed packages and original test release packages leaves a 
very ill defined state of a system on which to base bug reports.  I have 
broken my Test 1 system by trying to keep up with rawhide and would need 
to backtrack to a fresh install and start all the upgrading over again 
to do anything useful for this testing phase.  That is too much effort, 
particularly if I have to rinse and repeat again. The testing of RH8 and 
RH9 was much better coordinated, with most testers dealing only with 
released packages and packages explicitly claimed to fix particular 
bugs.  I also think it is *very* important that testers be given a 
coherent set of guidelines as described above by Robert J. Day.

Feeling impotent to help because my test sytem is hopelessly borked by 
rawhide updates.

Gerry Tool