HardwareDatabaseRoadmap

Differences between revisions 17 and 18
Revision 17 as of 2005-04-28 02:58:57
Size: 4521
Editor: intern146
Comment: Over to you Colin
Revision 18 as of 2005-04-28 09:50:34
Size: 4501
Editor: intern146
Comment: EditedSpecification
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
  * Status: ColinCharlesQueue, BrainDump, UduBof, DistroSpecification, DraftSpec[[BR]]   * Status: EditedSpecification, UduBof, DistroSpecification[[BR]]
Line 26: Line 26:
  * More than 20000 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
  * 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
Line 39: Line 39:
  * What fraction of users are having a good experience with a subsystem (e.g., sound)   * What fraction of users are having a good experience with a subsystem (e.g. sound)
Line 48: Line 48:
Server sided: Server-side:
Line 64: Line 64:
Client sided: Client-side:
Line 66: Line 66:
 * Rearrange the untranslatable 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
 * 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
Line 71: Line 71:
 * 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)  * 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)

Hardware Database Roadmap

Status

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

UDU Suggestions

UbuntuDownUnder/BOFs/HardwareDatabaseRoadmap (last edited 2008-08-06 16:34:36 by localhost)