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@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
Keith Lofstrom said:
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.
What is stopping you from just updating the 20 or so packages you want to test? I still don't see the benefit of trying to track 5 different trees and somehow magically merge them. It just causes confusion because person A sees a bug, but it has been fixed in another tree. How do you handle that?
Test what you feel qualified to test. Update what you want to update from Rawhide (like when you find a bug and want to see if the newer version fixes it). Report bugs. I don't see what the issue is. The current development model has worked up through RH 9...