The Linux Quality Database is proposed to make it easier for Linux users to give feedback to the Linux kernel developers by providing an easy-to-use web interface for logging both bug reports and successes with different kernel versions, and to make it easier for developers to track down bugs by providing boolean searches based on harware and kernel configurations, kernel version and patch level, and distribution used.
We want to log successes as well as bugs to help the kernel developers build confidence when something is working right.
Besides identifying specific problem areas, developers will be able to identify areas that have not been adequately tested so they can ask that Linux testers try them out, or try out combinations of features that might be expected to cause problems.
In a larger sense, this project is intended to improve the quality of Free Software in general, both by providing free tools for quality, such as the source code to the database application itself, and access to the hardware database that will be a component of it, as well as a site for advocacy: that one should make the effort to write quality software - and education: resources on how to accomplish it, better than simply trying harder - putting out a lot of effort will fix some bugs, but it's a lot easier if you have good tools, know how to use them, and observe good programming practices that tend to discourage bugs in the first place. See the articles section.
I feel that software must not just be Free, it must be Good.
-- Michael D. Crawford crawford@goingware.com
July 27, 2005: The articles which were previously published under the GNU Free Documentation License have been relicensed to the Creative Commons Attribution-ShareAlike license so that they qualify as Free according to the Debian Free Software Guidelines.
The dot-com crash disrupted my grand plans for The Linux Quality Database. I never was able to develop it. Nevertheless, the articles remain useful. I expect that I'll be writing more of them in the coming years. -- Mike
The Linux Quality Database is hosted through the generousity of Dotsrc.org, the international Open Source hosting service formerly known as SunSITE.dk.
I suggested this idea to the linux-kernel mailing list in May 2000 in a message titled Organized Linux QA? after subscribing to the list for a while to help resolve a problem I found with the 2.4.0-test series kernels on my laptop.
The problem got fixed, but I felt that many users who might like to contribute to testing new kernels would be put off by the process of reporting bugs to the list. The usual procedure is to mail a report to the list and wait for a patch to appear that might fix it. But the linux-kernel list has some of the heaviest traffic of any internet mailing list and there are many bug reports flying around as well as many proposed patches to different problems.
It's a huge job for the developers to keep track of all this stuff and in fact some things fall through the cracks, as the fixes to my bug did several times. I subscribed to the list to follow it up and persisted in resubmitting reports and requests that patches get adopted, but I suspect most people won't want to do that.
The 2.4.0 kernel has been in development a long time and while I was on the list there was a lot of discussion of how to speed up the process of future kernel versions. There were many suggestions such as working on fewer modifications with each new version, but I think a significant help would be to try to make things easier for the developers:
Yes, the kernel folks still have to write a lot of code for a new version but this can help them make sure it works right more quickly.
One thing I want to emphasize is that I don't want to impose some kind of big-company quality process on the kernel developers. I think that would be pretty presumptious of me, as I've never been a Linux kernel developer, I just subscribed to the list for a while to report a bug and then stayed around a while to enjoy the torrent of mail.
Specifically I won't even suggest that there should be a requirement that any particular developer participate in this at all, and developers should not have to track bugs assigned to them and close them or refer them back to testers.
It would be helpful if a developer wanted to participate, for example to report when a fix was available, but I want this to work just fine if no developer participates actively at all. It would be sufficient for this database to exist passively as a resource for developers to search through when they felt like it.
I also want to say that this is not about pointing fingers at Free Software programs that have problems - or the people who create them. While I'm doing this initial work to aid the Linux kernel development, it is actually my experience that the kernel is of very high quality. I have had specific problems with some free software (and certainly lots with proprietary software) but in general things work very well.
But I feel it is important to do better. If a company invests thousands of dollars in proprietary software licenses, they're likely to work with the vendor when a problem arises because of the commitment they made when they paid all that money. Linux often does not have this opportunity - it is very often the case that a user will judge the whole system based on their experience with a single $29 CD distribution and not give it a second chance if something goes wrong.
I do feel that, despite the best efforts of the desktop environment developers to write quality products, Linux is not ready for the desktop of the regular user. I know this from my experience working in technical support and specifically working to fix the problems with my parent's Macintosh whenever I visit them - the slightest little problem stops them cold. I think Linux has gained acceptance in the server market in large part because server users are typically programmers or experienced administrators and therefore have greater technical skills than the typical desktop user and are willing and able to deal with a problem when one arises.
When my mom encounters a problem with her computer, I can't ask her to download, apply and compile a patch. It's best if the problem doesn't occur in the first place.
I think quality is of especially great importance with the increasing use of Linux in embedded devices. An automobile MP3 player running linux is expected to work for years without any crashes or need for software upgrade (and no means may be provided to install new software).
The articles section discusses why why must make high quality software and provides resources on how to achieve that. Much of this material should be of interest to both programmers and regular computer users, for example I plan to discuss strategies anyone can use to test software in order to help out the developers.
I invite others to submit articles - contact Michael Crawford at crawford@goingware.com Eventually an automated interface will be provided for submitting articles. Please note that I ask that all the articles be copyrighted and licensed in such a way that at least verbatim copying is allowed, and that actual documentation use the GNU Free Documentation License as discussed in Why Free Software Needs Free Documentation.
This will allow the articles to be more widely disseminated so that they do more good, for example by including them with GNU/Linux distributions.
This website so far is pretty much vapourware. A lot of work remains to develop it before it will serve anyone's use.
If you'd like to participate, please join the developer's mailing list, and let's get started. To subscribe, send a blank message to:
You can get more information about the list by sending a mail to:
More information about the mailing list software can be found at SunSITE Denmark's Public Mailist Guide.
When we get something up and running we'll create a mailing list for site users as well.
New - documents for use by contributors to the site are now to be found in the site documents directory. This is where I'll be putting drafts of the design specifications.