HardwareDatabaseRoadmap
Hardware Database Roadmap
Status
Created: Date(2005-04-23T09:17:34Z) by MattZimmermanBR
Priority: LowPriorityBR
People: OliverGrawertLead, MatthewPaulThomasBR
Contributors: MattZimmermanBR
Interested: BR
Status: EditedSpecification, UduBof, DistroSpecificationBR
Branch: BR
Malone Bug: BR
Packages: BR
Depends: BR
UduSessions: 1, 4, 8, etc BR
Introduction
Create a roadmap for the Ubuntu hardware database and related projects.
Rationale
More than 20,000 datasets in < 30 days (currently 755 submissions a day on average)
- Collecting device and BIOS data, as well as xorg log/config and boot data
- Client points you to your online record on the second run
- Postgres server solution is in the desired target
- No inclusion of the client in reportbug yet (automated inclusion of the hwdb ID in bugreports)
- Client needs improvement to have the full planned feature set
Scope and Use Cases
- Analyze data collected in the database
- Import the data into a system suitable for reporting
- Generate summary reports
- How well a certain device is supported, and how popular it is
- What fraction of users are having a good experience with a subsystem (e.g. sound)
Two very important use cases:
- Desktop bug reporting tool: make it very convenient for the user to provide this additional information when submitting a new bug
- Online bug reporting tool: don't require an ID, but make it part of the dialogue between bug triager and reporter ("could you please create a hardware database ID for your computer and paste it in here?)"
See HwdbMaloneIntegration for more details
Implementation Plan
Server-side:
- Move the whole data and server application to a dedicated machine in the datacenter
- Offer existing information from the website -- the raw file collected is fine after some cleanup in the xml.
- Remove UUID, Serial number and MAC address from collected information.
- Remove these fields from existing entries; using a CGI to filter them would be fine.
- Disabling HTTP logs for submissions to ensure it's impossible to link submission to IP address of sender.
- Using a flat file database is fine; designing a real SQL database will take more time and the flat file is useful /now/, at least for bug reports.
- A real DTD needs to be designed for this thing at one point.
- Write a online device manager application to make the presentation of the raw data more user-friendly
- After the real SQL DB is in place:
- Getting hardware statistics and detailed reports
- Determining the quality of our current hardware support
- Find good/bad supported HW to improve the situation
- Invent some server security to prevent us from being slashdotted by marketing companies that might try to hook up scripts to our data
Client-side:
- Rearrange the non-translatable parts
- Invent some server security to prevent us from being slashdotted by marketing companies that might try to hook up scripts to our data of the code to be gettext translatable and put the .po file in Rosetta
- Additional automated test sets, including checks for second network, sound and video card
- Client-side update functionality for the dataset
- Pull more kernel information/module data and settings (use hal's defined but yet unused module options)
- Get more patches into the upstream hal version (which should be easier with the new hal 0.5), to make hwdb-client usable in Debian too (we get some malformed datasets from crossgraders with the wrong hal version but don't want to tighten the dependencies)
A new rocking "breezy" GUI so the user can’t resist playing with it and just must submit
Common (not roadmap related) stuff:
- Make the client configurable, so it can send to a local server instead
- Make a local server package for integration in standalone intranet helpdesk systems
Building a base for ubuntu HardwareCertification
Data Preservation and Migration
Packages Affected
User Interface Requirements
Outstanding Issues
- Meeting with mpt at UdU for UI review and planning of the breezy UI
UDU BOF Agenda