Project info for LinuxQuality

Created 7 Dec 2000 at 11:23 UTC by goingware, last modified 29 Jul 2005 at 04:07 UTC by MichaelCrawford.

Homepage: http://linuxquality.dotsrc.org/

Notes:

This is in the early planning and proposal stages.

Update: July 29, 2005 - and that's where it sat for five years while I struggled to survive the dot-com crash and then change careers. My grand vision for a bug database as described below went nowhere. The good news is that I did succeed in writing several articles on the general topic of software quality which have turned out to be useful and popular. Someone got tired of waiting and set up a bugzilla for the kernel. While it is not as featureful or as easy to use as the bugbase I envisioned, it gets the job done.

I have come a long way in my HTML/CSS design skills since throwing up the original site, and expect to rework it in late August. Suggestions are welcome.

Following is my original project description, posted way back in December of 2000, when the dot-com crash was well underway, but I had not yet come to fully appreciate the bad news.

Last may I made a proposal on the linux-kernel mailing list called Organized Linux QA? in which I suggested we build a web database that would make it easier for users trying out new kernels to submit both bugs and success reports, and in particular to store configuration information.

There'd be a database of available hardware components that one might try with linux, and users could create configurations from these that match the ones in their computers. A user could give a name to a preset config. When they have either a bug or some success to report with some kernel, they could enter the kernel version and patch level, paste in their .config file, and select the configuration preset name.

Developers would be able to search by boolean combinations of hardware items in the hardware config as well as option set in the .config file.

I want to be the first to say it's not my intention to try to impose some kind of process upon the linux kernel developers. That would be absurd on the face of it - I've never been a kernel developer, I'm just a guy who dropped into the list for a few weeks to work out a bug. For this reason there would be no requirement that a developer take responsibility for a bug or to close it, unless an individual developer wanted to work that way. Instead, it's my hope to make more information available to the kernel developers and to make it more organized and easier to access.

The backend code itself for this I'm thinking of writing using the Enhydra java application server. I expect to use the GPL for the license on the backend code we write itself but I want to see what other participants have to say before we settle on this.

License: Creative Commons

This project has the following developers:

goingware is a Lead Developer.
MichaelCrawford is a Lead Developer.