Testing pool for Oneiric SRU

Brad Figg brad.figg at canonical.com
Thu Dec 1 16:29:27 UTC 2011


On 12/01/2011 08:02 AM, Brendan Donegan wrote:
> On 01/12/11 15:58, Brad Figg wrote:
>> On 12/01/2011 05:20 AM, Brendan Donegan wrote:
>>> Hi,
>>>
>>> As the Oneiric -proposed kernel has become available for testing, we're about to commence with it. We're proposing to use our new testing pool functionality which you may have heard about to reduce the number of systems we need to test while still
>>> providing maximum device coverage. In a previous mail, Marc showed you the list of components that we've proposed as 'important' for the purpose of including at least one of each different device of that type in the testing pool. This is the list as it
>>> stands:
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0AphFraZYTghddElqTHl3NmZsWXVDYkMxcE5zX3EtR0E&hl=en_US#gid=0
>>>
>>> and this is the testing pool it created:
>>>
>>> https://docs.google.com/spreadsheet/ccc?key=0ApQ2JshzVOLydEtFOWxPZ2h6R3BhcDFDbnV4SHJuT1E
>>>
>>> There is a link to the Ubuntu certification page for that system so you can have a look at which components it has. This is mainly for transparency.
>>>
>>> As with Marc's email I would urge you to check the components on the first spreadsheet with an X next to them, as these are the ones that *are not* considered for the purposes of shrinking the testing pool. Marking one of them as important will allow the
>>> tool to include at least one system that includes each different component of that type and potentially *increase* the number of systems in the pool. The goal is to cover as much hardware as possible with a reasonably sized testing pool.
>>>
>>> Thanks,
>>>
>>>
>>>
>>
>> I don't see the Acer server platform that is producing bug
>> 897773 listed in the above document. Since that is the only
>> one that is showing this issue, I think it would be good to
>> have it added.
>>
>> Brad
> It could be that whatever component is triggering this halting is not being considered for the purpose of filtering the testing pool. Perhaps we need to keep the testing pools open to including specific systems manually, if we can't figure out what
> component is causing this (which seems far off at the moment)

I agree. Just wanted to mention this specific case.

Brad
-- 
Brad Figg brad.figg at canonical.com http://www.canonical.com




More information about the kernel-team mailing list