Updates to Mesa in an LTS - How do you get one?

[Philip Wyett]

On Wed, 2009-04-15 at 23:01 +0200, Martin Pitt wrote:
> Hello Philip,
> 
> Philip Wyett [2009-04-15 19:20 +0100]:
> > After pain of dealing with the RC Mesa in Ubuntu 8.04 ever since, I
> > decided to email the technical board about why it and all releases
> > should be based on a full release of Mesa + patches only, giving
> > developers a clean base to work with. Mark Shuttleworth replied in a
> > positive manner and indicated the prime example of why yes we should
> > which was Firefox. This then got taken to this list and the public and
> > after I filed the following general bug for an update of Mesa complete
> > to a release.
> > 
> > https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/344710
> 
> The Technical Board is indeed the correct institution to override the
> SRU team. I wasn't aware that this was discussed at TB before, do you
> have a link to their official decision? If the TB positively decides
> over this, then of course I'll accept the patch into -proposed.
> 

As I mentioned in my original email. I emailed the technical board and
received a reply from Mark and then Matt Zimmerman thought it should be
public discussion and posted to the devel list, not this list as I
previously stated. Link below of his original mail.

https://lists.ubuntu.com/archives/ubuntu-devel/2009-March/027777.html

The thread got one reply from me then died.

It has never been a formal subject of the technical board. Apologies if
it came across that way.

> I am aware about what we did with Firefox, but it's not really
> comparable. A broken Firefox in an SRU is very bad, but at least it
> can be rectified with another update. A broken X in an SRU is a
> disaster, since it wouldn't even allow the user to get to
> update-manager any more. Also, Firefox is not very hardware specific,
> so it can be regression tested thoroughly by a few developers.
> Anything touching hardware specific things such as mesa are virtually
> impossible to regression test for us developers.
> 

The patch concerned only affects one driver base and I was running it
with no issues from the day I created it up until this weekend when I
rebased the Debian Stable mesa-7.0.3-7 with a couple of base patches
from the current package in hardy.

With regard regression testing. Doesn't Canonical as part of it's
support structure have test facilities to do this kind of testing? I
would assume so when packaging up for larger customers with support
contracts?

> We did get burned by such updates in the past, this is why I am so
> anal about them. 
> 

Yes, I felt the last biggy personally. A fun time - the good old
days. :-)

> > OK, that is the background. How do you successfully get an update? I think
> > I have tried to do my part and contribute.
> 
> Contributions are welcome and appreciated, but they still have to follow the
> SRU rules, I'm afraid. This is why we concentrate development and testing
> efforts on the development releases, since the first thing we need to maintain
> in stable releases is stability. Millions of users out there rely on that.
> 
> I regret and apologize that I didn't reject the hardy task right away
> back then, to save everyone some work. I am doing that more timely
> now.
> 

Maybe a quick rejection earlier would have been better. It would have
prompted me to rebase the Debian Stable for Crystal Space users and
others who wanted it a little earlier. But no harm done as the CS
project has not made a release in a while and the code that would
trigger the bug I created the patch for is still sat in SVN.

> Thank you for your understanding, and again sorry for the work you did on that
> in vain,
> 
> Martin
> 

Stop apologising please. OK, it's happened as it's happened and it
something that we can all learn from as Ubuntu evolves and grows even
more.

As a desktop OS, Ubuntu LTS's cannot forever keep to this strict SRU
policy. A year after an LTS is released it is essentially struggling
with new systems/laptops and the internal hardware they posses i.e.
graphics, audio, webcam etc. and some flexibility I think needs to be
discussed of how to address it sooner rather than later.

As an example...

A business rolled out 20 hardy systems 6 months ago. This or next year
they need to be replaced due to failure. The exact same machines are no
longer available due to the evolving and volatile hardware market.
Similar machines at this time may have one or two pieces of hardware
hardy just cannot handle, but this business needs to keep with hardy a
newer release is not an option.

This is an issue companies are likely to face if they go with Ubuntu in
business and cannot be taken lightly as someone has to foot the bill
somewhere.

Regards

Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20090415/5e3ef5fc/attachment.sig>