All right. We had a bit of discussion on this in #fedora-devel. Here's a quick summary of what the project seems to need.
(1) A database that holds hardware information (2) A GUI tool to submit that information (3) A web interface to use that information
Requirements and Functionality ------------------------------
Primary Purpose of the System: To allow users to know if their hardware works with Fedora/Red Hat Linux.
Secondary Purpose: To allow users to resolve hardware issues with Red Hat Linux products.
How this is accomplished: By creating a database of hardware and how well it works.
Specific Implementation: Creating the database from end-user data, which has the added advantage of giving people the opportunity to participate in the Fedora project.
Value of the Product: If well-designed, the product will allow both Fedora and Enterprise customers to have confidence that their hardware works with our software.
This leads to the following requirements:
* The system needs to hold hardware information in a logical fashion.
(Meaning, the more specific fields that we can get about the hardware outside of a "comments" field, the better.)
* The system needs to be easily cross-indexable. * The system needs to be as easy as possible for the end-user to use. * It must be likely that the average end-user will submit their information. * The submission must take no longer than 10 minutes, though under 5 minutes would be ideal. * The system must be flexible enough to adapt to new types of hardware that we cannot predict. * The end-user of the web product must be able to determine the quality of the data that they are presented with. * The end-users privacy must be protected to the exact degree they desire.
What to use -----------
When it comes to (1), we'll want a real database solution, probably based on PostgreSQL. Ideally, I'd like to see if there's some high-level solution already in existence that can be modified according to our parameters. We could build from the database up, but the incredible amount of effort that this project requires could be considerably lessened by some higher-level tool.
Any suggestions in this area?
For (2), we'll probably have to roll our own. Does _anything_ like this already exist in the open-source world?
For (3), it's clear that there are components of various systems that will do various parts of what we need. For example, if we want to rank comments, Advogato has been suggested, for the reason of algorithmic quality and code quality. Slashdot is an alternative, however that seemed to be not as well-liked initially. Are there any less well-known Open Source projects that would suit these needs better than Advogato?
As far as the actual browsing of the hardware, are there any projects that would give us a leg up here?
Now, it would be possible to use a sort of modified Bugzilla to do what we want. The problem seems to be that Bugzilla is a system much more complex than our hardware database is going to be. The volume of our hardware database is going to be pretty high, and a Bugzilla with a high level of submission requires a lot of maintenance, volunteer and otherwise (witness bugzilla.mozilla.org).
In general, it seems that Bugzilla is out, from consensus. Feel free to argue -- we're at the "throwing ideas around" stage.
Languages ---------
GUI: PyGTK. It's clearly the Red Hat standard for GUI projects.
Backend: SQL and Python. Some C if required for interfacing with Open Source Projects we use.
Web Interface: PHP or Python. Once again, this might also depend somewhat on the other projects we integrate.
Other Implementation Notes --------------------------
We have a lot of tools that can get data for us:
lspci, dmidecode, dmesg
What I _don't_ really think would be fun would be parsing the text output of those programs. MKJ thought it would be ideal if dmidecode could give us XML. Anybody know if there's a tool that already does this, or something we could start with? hwbrowser seems to make sense of that data somehow -- is there a way to get data out of it? Who's the maintainer of hwbrowser?
It would be a good idea to have people submit data and have a "No Problems Reported" status.
The program would probably be a small applet that exists in the tray until run. After that, it should disappear forever. The alternative is an icon on the user's desktop saying "submit your hardware information" or something like that.
Priorities ----------
(1) A backend which accepts data. (2) A method of populating the backend. (3) A method of browsing the submitted data. (4) A method of using the submitted data to resolve problems. (5) Connecting the submitted data to driver downloads. (A great idea from Warren.)
Cost ----
* One computer to act as the DB server, etc. * One computer to run development versions. * Bandwidth -- I'm not sure on this one, how much do you think it would take?
Okay, this is just a rapid sketch! More suggestions!! If I can get a space somewhere, I can maintain this document as a web page. I'm sure I left a lot of stuff out. It's a big project. :-)
Also, who wants to actually work on this, and on what part?
-Max K-A