HardwareDatabaseRoadmap

Differences between revisions 12 and 13
Revision 12 as of 2005-04-24 01:15:50
Size: 3146
Editor: intern146
Comment: priority
Revision 13 as of 2005-04-27 06:32:47
Size: 4151
Editor: intern146
Comment:
Deletions are marked like this. Additions are marked like this.
Line 76: Line 76:
=== UDU Pre-Work === === 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?)"

Hardware Database Roadmap

Status

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)