Certifying the different configurations of the same system

Registered by Ara Pulido

In the enablement projects, the HWE team usually works enabling different configurations of the same hardware (with or without bluetooth; with nVidia or Intel graphics, etc.). In Certification we are not taking care of these different configurations and usually we just certify one of the configurations.

In the case of the desktops, the HWE team normally receive just one system and the additional configuration. For example, they receive a desktop with Intel graphics and, apart, a nVidia card (the second configuration). The HWE team will install the card during the enablement process. This is not a possibility for the certification team, if we keep testing the same way we do right now.

For laptops the situation is a bit better, as the enablement team would normally receive another laptop with the second configuration. But, again, if we aim to certify all the different configurations, we need to revisit the way we test, as the growth expected for the number of certified systems can quickly overload the capacity of our labs.

This same problem occurs sometime after the system has reached RTS. After an enablement project has been finished, the customer might want to enable another configuration of the same system. This situation also needs to be handle as part of this blueprint.

Blueprint information

Status:
Started
Approver:
Kevin Krafthefer
Priority:
Medium
Drafter:
Ara Pulido
Direction:
Approved
Assignee:
None
Definition:
Approved
Series goal:
None
Implementation:
Started
Milestone target:
milestone icon november2011
Started by
Victor Tuson Palau

Related branches

Sprints

Whiteboard

== Definition of done ==

* We have a frequently updated and reliable system that generates the minimum amount of systems that need to be tested for each type of regular testing (SRU, weekly).
* We have an inventory policy that improves the way we store systems in our labs, based on the activity each system has.
* The different certified configurations are shown in the public certification website in a way that is usable for the end-user and making clear which release a particular SKU was certified for, and which combination of components form a SKU
* We have a policy on the criteria on what configurations are we certifying for each system.
* The post RTS project are managed in the same way.
* Unless there is a physical exception (lack of hardware, etc.), all the different SKUs for a system are tested

The following text reflects David Bensimon views and are currently not part of the implementation plan/actions approved for the certification team (-victorp):
==DB-START==
The goal of having a certification site is making certified hardware available to end users. Without assisting customers/enterprises by indicating where to purchase the certified model (in its tested configuration), I feel that we are not achieving our goal. We have already received many reports from support customers with post-purchase issues of a model which was posted on the certification website. The issue was present because it was a different configuration. We need to apply pressure on manufacturers to follow certification rules (set of criteria) to get the "Ubuntu Certified" sticker.

For the Hardware Certification page to be useful we need to:
- Show in which markets the PC is available (country flag or country preference).
- Link to manufacturer's page for that specific Model/SKU/Configuration (modifiable redirect URL can be used).
- If the manufacturer does not differentiate between configurations (such is the case with Dell), we need to make this a contractual requirement.
- Keep manufacturer accountable for changes in configuration by applying pressure to accept returns if they change hardware controllers, hardware revisions, or BIOS versions without certifying that change with us first.

David Bensimon
==DB-END==

(?)

Work Items