HardwareDatabaseRoadmap
4151
Comment:
|
4157
+ mpt at ogra's request
|
Deletions are marked like this. | Additions are marked like this. |
Line 10: | Line 10: |
* People: OliverGrawertLead, NeedsSecond[[BR]] | * People: OliverGrawertLead, MatthewPaulThomas[[BR]] |
Hardware Database Roadmap
Status
Created: Date(2005-04-23T09:17:34Z) by MattZimmermanBR
Priority: LowPriorityBR
People: OliverGrawertLead, MatthewPaulThomasBR
Contributors: MattZimmermanBR
Interested: BR
Status: BrainDump, 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
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)
Implementation Plan
Data Preservation and Migration
Packages Affected
User Interface Requirements
Outstanding Issues
UDU BOF Agenda
- Where are we now?
more than 18000 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 works
- no inclusion of the client in reportbug yet (automated inclusion of the hwdb ID in bugreports)
- client needs improvement to have the full feature set I planned
- What can we do with the current data ==
- 1st usecase is a online device manager with log viewer
- getting hardware statistics and detailed reports
- determining the quality of our current hardware support
- find good/bad supported HW to improve the situation
- loads of statistics are possible
- What's the future?
- fixing the remaining bugs in the client indeed
- rearrange the untranslateable parts of the code to be translatable and put a .po file in rosetta
- additional automated test sets
- checking for second network, sound and video card
- client-side update functionality for the dataset
- 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
- pull more kernel information/module data and settings (use hal's defined but unused module options)
- invent some server security to prevent us from being slashdotted by marketing companies that might try to hook up scripts to our data
- get more patches into the upstream hal version (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 design so the user cant resist playing with it and just must submit
- building a base for ubuntu hardware certification
UDU Suggestions
- Get UI review of application with mpt at UDU
- Offer existing information from the website -- the raw file collected is fine.
- 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.
Two 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?)"
UbuntuDownUnder/BOFs/HardwareDatabaseRoadmap (last edited 2008-08-06 16:34:36 by localhost)