Testing test releases: do not update

[Ernest L. Williams Jr.]

On Thu, 2004-02-26 at 17:36, Jef Spaleta wrote:
> Mike A. Harris wrote:
> > as Jef Spaleta puts it "rawhide might kill babies"
> EAT BABIES
> not KILL
> totally different...totally....yeesh
> 
> And you slyly glossed over the one valid point in the thread...
> shmuel siegel wrote:
> >> I think that a lot of the confusion comes form a lack of a
> >> public test plan and the lack of guidelines for testers
> 
> If i would agree with anything..i would agree...that a lot of
> potentially useful testers, enthusiastic users who want to contribute in
> some way, are unduly confused about what is really expected of them
> during different phases of the testing process.
> Or if not confused...just completely unaware, and don't really have a
> good idea of where to start. And I'm warning you, trying to build some
> sort of communication mechanism(s) to provide better guidance during
> testing is own my personal agenda....which means I'm going to poke
> developers in the eye and see if I can get a few crusty nuggets of
> useful wisdom out of them, in a effort to cobbling together something
> aimed at the potential tester, to get them started with less overall
> emotional trauma. And just to be mean...i'm not going to give you my
> personal timescale to start the attack....but you've been
> warned....start watching the skies.
> 
> And i could probably argue, that people who have been involved with
> previous rhl beta processes, probably are carrying some misguided
> expectations about how the testing is going to work for FC as well
> (though i think yer post addresses these old hats to a large extent.)  I
> think everyone really needs to come to the table with an understanding
> of where the real development bottlenecks are. In my opinion, the
> biggest bottleneck is utilization of developer time...developer time is
> the scarce resource. Building a testing process thats most convenient
> for the testers but puts an undue burden on the developers isn't a
> process based on the realities of the resource economics involved.  
What is the policy on feature freeze during the testing cycle?  When a
package is released such as for Fedora 2 Test 1 are the features frozen?
If the features are indeed frozen should not the priority shift towards
bug fixes?   Just asking more questions about the development/testing
cycle?  I am not complaining.





> We
> can argue till we are blue in the face about the reality value of having
> an extra tree, from the testers point of view, but there is no getting
> around the fact that how much really gets done between releases in terms
> of building the bits is choked by how many developer manhours there are
> to burn on the innumerable priorities. Let's put it this way....no one
> can honestly argue that developers are sitting playing games waiting for
> actionable bug reports to roll-in. But i also think, in the new world
> order of the more open Fedora process, there is a place to make an
> effort to recognize the contributions being made from outstanding
> testers. I'm not talking about bending the testing process to their
> will, but a considerate way to give testers recognition for letting
> test1 releases meltdown their boxen..for the good of mankind.
> 
> -jef"you will pay for misquoting me..pay..dearly"spaleta      
-- 
Ernest L. Williams Jr. <ernesto at ornl.gov>