Testing pool for Oneiric SRU
Brendan Donegan
brendan.donegan at canonical.com
Thu Dec 1 16:38:34 UTC 2011
On 01/12/11 16:29, Brad Figg wrote:
> 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)
Heh. Or it could be that this system isn't certified with Oneiric (which
this testing pool is for). I'll make a Lucid one and see if it turns up
(now I'm curious)
>
> I agree. Just wanted to mention this specific case.
>
> Brad
More information about the kernel-team
mailing list