Mesa update as SRU?

[Steve Langasek]

On Thu, Apr 10, 2014 at 10:33:41PM +0300, Timo Aaltonen wrote:
> >> This would allow a more sane way to provide BDW support in
> >> 14.04.1 than backporting a big pile of commits and maintaining
> >> the franken-mesa ourselves..

> > Is 14.04.1 the right time frame to be targetting Broadwell support,
> > or should we be aiming for 14.04.2 instead?  I.e., would this fit
> > better the normal point release hardware enablement stack process?

> I'm afraid 14.04.2 is too late for the first batch of devices to be
> shipped by our OEM partners "before EOY".. (being vague on purpose,
> the release schedules aren't public yet AIUI). That's also why the
> trusty kernel has a i915_bdw module backported from 3.14+fixes.
> Attempting the same for mesa is unknown territory though, kernel is
> easy in that regard.

OK.  I realize that trying to backport all the pieces onto mesa is not
necessarily less risky than taking the new upstream version; but that just
makes me worry that neither is appropriate for an SRU.  Have you considered
the possibility of an early "pre-release" version of the enablement stack,
made available to OEMs that will ship before EOY, and automatically updated
to the official 14.04.2 enablement stack once it's out?

> > I am in general not happy with the idea of all users being given a
> > new version of mesa via SRU, because it's very difficult to ensure
> > that the package doesn't introduce regressions.  "Community
> > testing" is always self-selecting, and for a package with as broad
> > an impact as this, I don't think it will be adequately tested
> > without an explicit test plan that details our hardware coverage.

> Indeed, it would be important to test on several GPU generations of
> each vendor (Intel/NVIDIA/AMD). We've done that before though for a
> major update that was close to feature freeze on a recent release..
> forgot which one it was :)

Right, and even then there's an important difference between doing such an
update late in the development cycle, and doing it after release once we've
told our users that it's "stable" and promised them that we wouldn't
introduce regressions.

> Anyway, I could draft a testing plan to see how it might work out this
> time.

Ok, please let us know what you come up with.

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20140410/adfc40eb/attachment-0001.pgp>