Managing Fedora Testing

[Keith Lofstrom]

Keith Lofstrom said:
> ...
> Instead, I would divide up the work into domains so that people can
> choose a domain and test in that.  Where to draw the line is difficult,
> but I would probably make the domains "kernel and drivers", "installation
> and update", "X and desktops", and "applications".  Obviously, many
> problems will cross domains, but to the extent that you can partition
> things you reduce the scope of most problems.

William Hooper replies:
> What is preventing you from updating the "domain" you choose from Rawhide
> and testing?

Nothing prevents me from doing that, but it does not resemble my
goal, which is to work with a group of like-minded individuals to
locate functional and conceptual errors in a "distro" - that is, a
collection of software packages that play well together.  If all
packages in a distro were autonomous and well behaved, then it
would be easy to do as you say - in fact, there would not need to
be a Fedora test team, just individual test teams associated with
each package, checking conformance to specification.  If there were
just 20 packages in a distro, a domain system would not be useful,
twenty items is easy to keep track of.  

But as it is, there are thousands of packages in the Fedora distro,
with strong coupling between many.  Without further partitioning,
that is a recipe for engineering disaster.  No mind is big enough
to encompass all the interactions.  So you break the problem down.

"I am here to help" followed by "you're not good enough, go away"
is OK if you want a late, hard-to-use, buggy distro.  A response of
"here, work on these things, leave me alone" is quite a bit more
useful.  I am proposing one way to partition useful testing tasks
for the non-elite, a technique that works well in other fields. 
There are no doubt other techniques that work well, too.  

The testing performed so far by the elite has been incomplete, and
focuses on install/kernel/code-structure issues rather than usage
issues, because that is where this particular elite lives.  Out here
in the "other" world, where an error message should be a pointer to
a config file rather than a source code file, somebody has to check
whether the error messages really help Jane User fix her config files.
The best person to do that is Jane.  How can we help her participate?
If she cannot participate, in what sense is this a community effort?

If you limit debugging to a small subset of eyes, you will only
find a small subset of bugs.  The technical name for this approach
is "Microsoft".

Keith

--
Keith Lofstrom           keithl at ieee.org         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs