Status

• Created: 2005-04-23 by MattZimmerman

• Priority: LowPriority

• People: OliverGrawertLead, MatthewPaulThomasSecond

• Contributors: MattZimmerman

• Interested:

• Status: EditedSpecification, DistroSpecification, OliverGrawertQueue

• Packages:
• Depends:

• UduSessions: 1

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
• Reports:
  • Machine related reports
    • Overall reports are very useful for laptops where device custmization is rare
    • Mainboard/CPU related reports to have an overview of certain architectures, CPU speeds or Mainboard vendors
  • Device related reports
    • Common device reports (percentage used within the number of subscriptions)
    • Detailed device reports based on the user feedback from the questionnaire to get a functionality overview for a certin device
    • Class based device reports to find the best supported device for a certain class based on questionnaire and hardware data
  • User experience reports
    • Common reports based on the feedback from the questionnaire, not related to the devices

The above reporting structure can easily be in place for breezy, more detailed or crossreports are posible, remember that the server side is independent from the release schedule, so additional reports can be introduced at any time.

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

• MattZimmerman: "The hardware database roadmap needs to address reporting; it is critical that we be able to make use of this data that we have collected. It is a higher priority to summarize the data that we can collect now, than to collect more sophisticated data."

---

CategoryUdu CategorySpec