#1 Complaint about Ubuntu: Updates break things

Cody A.W. Somerville cody-somerville at ubuntu.com
Sat Dec 20 01:57:58 GMT 2008


On Fri, Dec 19, 2008 at 6:27 PM, Sam Tygier <samtygier at yahoo.co.uk> wrote:

> Bryce Harrington wrote:
>
>> On Fri, Dec 19, 2008 at 03:09:01PM -0500, Cody A.W. Somerville wrote:
>>
>>> For example, I remember one time an update to the nvidia binary blob
>>> drivers
>>> caused the xserver to fail to start in certain cases. It didn't affect
>>> the
>>> *right* people or *enough* people for it to get the attention it
>>> deserved.
>>>
>>
>> When did this happen?  I cannot recall ever seeing a binary X driver
>> update accepted by the SRU team.
>>
>
> could that be the X update that cause X to fail for many intel users back
> in ~2006 (i think). that led to the introduction of the proposed repos (or
> at least the introduction of the proposed repo was closely correlated in
> time).


No, this was not the infamous X update I was referring to. As to the exact
update that caused the issue I discussed, I'm not entirely sure. However, it
was an X related update and the little details I do remember would indicate
to me that it would not have mattered if the source code was available or
not.


> sam


If folks *are* looking for specific examples, just ask the Canonical OEM
Services project engineers ;]

However, I think a more productive discussion would instead focus on how we
can properly test tricky updates and updates that have a higher risk for
regression and how we can get simpler updates out quick and effectively
while not sacrificing quality testing.

To start the ball, I'll throw an idea out: the introduction of multi-tier
system that would classify an update based on an agreed set of quantitative
and qualitative criteria such as where the component falls in the stack (ie.
distinction between the kernel, desktop environment, and an application),
popcon score, etc. etc. Each tier would demand a different degree of
testing, verification, time in -proposed, sign off from different parties,
etc. That way we ensure appropirate people are looking at the SRUs,
appropriate testing is occuring, and appropriate happiness is occuring! :)

Cheers,

-- 
Cody A.W. Somerville
Software Systems Release Engineer
Custom Engineering Solutions Group
Canonical OEM Services
Cell: 506-449-5899
Email: cody.somerville at canonical.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20081219/043e3755/attachment.htm 


More information about the ubuntu-devel mailing list