HardwareDatabaseRoadmap
Differences between revisions 3 and 4
|
Size: 1642
Comment: added initial data
|
Size: 1950
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 16: | Line 16: |
| * client points you to your online record on second run | * client points you to your online record on the second run |
| Line 19: | Line 19: |
| * client needs a lot of improvement to have the full featureset i planned | * client needs improvement to have the full featureset i planned |
| Line 21: | Line 21: |
| = What can we do with the current data = | = Ideas and suggestions = == What can we do with the current data == |
| Line 28: | Line 30: |
| = Whats the future ? = * more automated tests |
== Whats the future ? == * fixing the remaining bugs in the client indeed * additional automated test sets |
| Line 31: | Line 34: |
| * update functionallity for the dataset | * client sided update functionality for the dataset |
| Line 33: | Line 36: |
| * make a own server package for integration in intranet helpdesk systems * pull more kernel information/module data and settings * invent some server security to prevent us from being slashdotted by marketing companys that might want to hook up to our data * get more patches into the upstream hal version (easier with hal 0.5), to make hwdb-client usable in debian too (we get some malformed datasets from crossgraders with the wrong hal version) |
* make a own 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 companys 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 dont want to tighten the dependencys) * a new rocking "breezy" GUI so the user cant resist playing with it and '''must''' submit |
Priority
People
Goal
Analyze data collected by the Hoary hardware database client, and consider improvements for Breezy.
Where are we now
more then 16000 datasets in < 30 days (currently 763 submissions a day in 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 featureset i planned
Ideas and suggestions
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
Whats the future ?
- fixing the remaining bugs in the client indeed
- additional automated test sets
- checking for second network-, sound- and videocard
- client sided update functionality for the dataset
- make the client configurable, so it can send to a local server instead
- make a own 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 companys 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 dont want to tighten the dependencys)
a new rocking "breezy" GUI so the user cant resist playing with it and must submit
UbuntuDownUnder/BOFs/HardwareDatabaseRoadmap (last edited 2008-08-06 16:34:36 by localhost)