[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Testing test releases: do not update



On Thu, 26 Feb 2004, Jef Spaleta wrote:

>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.

Indeed.

>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.

*EXACTLY!*  Someone *GETS* it.

It's the same thing with bugzilla.  Bugzilla is *NOT* a tool
created for end users.  It is a tool created for _developers_,
and while it is useful for end users also, wherever there is a
tradeoff in the UI or featureset between bugzilla being more
beneficial to developers and less so for end users, the 
developers win hands down, because it was a tool created for 
developers first and end users second.  I've seen many people 
over the years suggest various ways that they would like to see 
bugzilla "improved" to make it easier for them to use.

While there are very likely ways in which bugzilla could be
improved to make life easier on an end user without making life
more difficult for a developer, most of the suggestions I have
seen in the past are end user suggestions for how to make
bugzilla a breeze for end users to use, which ends up resulting
in a useless tool for developers.  If we were to listen to those
people and make bugzilla do that, it would result in bugzilla
being a breeze for users to file 3 times as many bug reports,
probably most of them being useless to developers and ignored, or
causing developers to have to spend 2-3 times as much time using
bugzilla to get work done.  That is not a good tradeoff, and 
would make bugzilla a failure.

A similar concept is what we are seeing here with suggestions to 
make "branches" of rawhide, etc. IMHO.


>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.

Exactly.  There are only so many man hours to go around.  Every
minute spent duplicating work, or being delayed to jump through
hoops for some extra process for no real major gain to the goal
at hand, is less work that is going to get done before the ever
encroaching /deadline/.  Less work done == final product that
isn't as good.


>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.

Unless they're /testing/ DRI 3D acceleration crashing bugs of 
course, but otherwise I agree.  <grin>


>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.

I agree here also.

I would like to personally thank each and every person who 
volunteers to spend their own time downloading and installing 
Fedora Core 2 test 1, or any future test release, as well as 
those hardworking individuals who update to rawhide frequently 
and put their system in serious risk, possibly having to 
reinstall the OS several times, and pulling out their hair.  
Thank you very much for testing our unstable work in progress 
that can and probably will destroy your hard disk, set your house 
on fire, and make your video card blow your monitor to bits.  
Please continue to update to rawhide's finest h-bomb builds, and 
subject your systems to destruction.

;o)




-- 
Mike A. Harris     ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]