Posts tagged with 'hardware certification'

Last week, at UDS, I was asked several questions about how Ubuntu Certification worked. I decided I would start a set of blog posts about several aspects of the certification programme, for people willing to know a bit more about how we test and what.

One of the most confusing bits about Ubuntu Certification are BIOS options. In several ocassions I was asked the questions whether UEFI (with and without Secure Boot) was going to be added as part of Ubuntu Certification or not.

The answer is both yes and no. I will explain it a bit more in detail.

In Ubuntu Certification we don’t test BIOS options, nor we change them. We try to install Ubuntu with what it comes with the system from factory, and it needs to work up to a certification level using those options. That means that if it is using Legacy BIOS, we will be testing Legacy BIOS, if it comes with UEFI without Secure Boot, that is what we will be testing. If it comes with Secure Boot enabled, Ubuntu will need to install out of the box with the keys already in that system.

From 12.10 we have started to parse the BIOS information as part of the testing process:

Same thing for BIOS options. We test with factory default options, and only those. The goal of doing this is that Ubuntu Certified systems should provide and out-of-the-box Ubuntu experience. In some cases, tweaking BIOS options can improve the situation for non working systems, but that is something we don’t want to acept for Ubuntu Certification.

[...] we are planning to close down the “Ubuntu Ready” programme in time for Oneiric Final Release.

The aim is to simplify the public Canonical endorsed certification programme to only one:“Ubuntu Certified“.

To straighten out any confusion about what our certification offering will be here is a quick fact sheet about certification:

Existing Ubuntu Ready Certificates
We will not be offering new “Ubuntu Ready” services to OEM/ODMs. The existing Ubuntu Ready certificates will be maintained on the public website until the applicable releases reach end of life.

Remote Testing
We will continue to offer testing tools to partners and the community.The objective is for a common test tool for partners and community will be available within the Ubuntu ISO (from Oneiric).

Ubuntu Certified for Clients
Ubuntu Certified will continue to require hardware to be submitted to Canonical for testing. Ubuntu fortnightly Stable Release Updates means that certified systems are required to be tested every 2 weeks to ensure no regressions are introduced.
Remote testing can be used by partners as a way to assess if certification will be successful before engaging in a contract with Canonical.

Ubuntu Certified for Servers
While Certification of single servers follows the same process than client certification, we are concentrating our efforts on Certifying full server lines from OEMs.
In order to achieve this objective, the full server line is analysed by the appropriate TAM, a component matrix is produced and small representative set of servers is provided to Canonical by the OEM to test in-house, while the rest of servers are test remotely.

Ubuntu Certified (Pre-install Only)
A OEM or ODM shipping a pre-install custom ISO with their systems can apply for Ubuntu Certified (Pre-install Only).

Ubuntu Friendly Ubuntu Friendly in not a Canonical certification programme. Ubuntu Friendly is a Ubuntu community hardware validation programme that recognises the need for community and partners to list various degrees of working Ubuntu hardware publicly. At the same time, we expect this initiative to increase the visibility of which hardware components work with Ubuntu.
Participation in Ubuntu Friendly is free, done in the open and will utilise the remote testing tools provide by Platform Services.

Discontinuing Ubuntu Ready

If a user goes to the Ubuntu certification site, what he or she will find, apart from a list of certified systems, two different types of certification Ubuntu Certified and Ubuntu Ready.

Having two commercial hardware validation programs confuses the customer, as it is quite difficult to understand the differences between the two. For this, an other problems with the programme, we have decided to discontinue the Ubuntu Ready programme in 11.10.

Presenting Ubuntu Friendy

Instead of just removing Ubuntu Ready, we would like to start a non-commercial new hardware validation programme, created by Canonical, and with co-ordination with the rest of the community. This new programme is called Ubuntu Friendly (although the name might change).

The great thing about this new Ubuntu programme is that it will be completely community driven. There won’t be any commercial requirements for systems to be Ubuntu Friendly.

Although all the specifics of the programme will be discussed at UDS Oneiric, the basic ideas of the programme are:

Anyone will be able to test their systems and provide test results.

Anyone will be able to review and provide feedback on the results (something like triaging bugs in the Bugsquad). All the test results will be public (except those made it private by the certifiers)

Only a small subset of people (certifiers) will be able issue the Ubuntu Friendly certificate, based on results (in the same way Bug Control is a subset of the Bugsquad that have more permissions to work with Ubuntu bugs). There will be a formal and specified way to apply to be a certifier.

Many positive results (and not just one) for a given model and hardware configuration will be needed to mark the system as Ubuntu Friendly.

All the client tools to test Ubuntu, and the tests themselves, will be open source.

UDS Oneiric

Most of the specifics of the programme will be discussed during UDS Oneiric, during two sessions, on Wednesday:

This blueprint will contain the work needed to be done in terms of the technical infrastructure that is required to make the programme possible: testing tools, backend infrastructure, etc.

If you are interested in hardware validation and would like to share your ideas and make this project possible, feel free to subscribe to the blueprint and attend the sessions at UDS. And remember that remote participation is also possible!

After two years and a half in the Ubuntu QA team I have moved to the Hardware Certification team, on Platform Services. I was very happy to be given the opportunity to join the Hardware Certification team and I couldn’t reject. I am very excited to be able to help in the goal of making Canonical profitable.

How will that affect my collaboration with Ubuntu QA

It is been a great pleasure to work all this time with a great group of people (both Canonical and non-Canonical). Obviously, as working directly on Ubuntu QA won’t be part of my paid job, I won’t be able to dedicate it as much as time as I did before. So, first of all, sorry if I am not getting back to you as quickly as I did in the past. But I love the Ubuntu QA community and I am still part of it. I will still be working on some of the things I did before, in my spare time. There are some projects, like the Desktop Testing Program or Desktop Testing Automation that are very close to my heart and I would like to stay somehow involved with them, I will try to attend the Ubuntu QA meeting at least twice per month and I will stay active in the ubuntu-qa mailing list.

The Hardware Certification Team

Having a successful certification program is both beneficial for vendors, ensuring their costumers that the hardware will work with Ubuntu, and the Ubuntu community, as they have access to the list of systems that work out of the box. We agree that sometimes we don’t expose the Hardware Certification program to our community as much as we should. There are people very active in the Ubuntu development that don’t know that Canonical has a public website where people can check what systems are certified to work with Ubuntu or even that the certification program exists. We don’t keep it as a secret, though; the Hardware Certification team has been attending UDS, our main testing tool is open sourced and installed by default in Ubuntu and, as I said, the systems that have been certified are published. I understand that we can do a better job explaining how the hardware certification program itself works and keep it more in the open, accepting suggestion and criticism.