Mesa update as SRU?

[Timo Aaltonen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10.04.2014 22:00, Steve Langasek wrote:
> Hi Timo,

Hey Steve,

> On Thu, Apr 10, 2014 at 12:49:49PM +0300, Timo Aaltonen wrote:
>> Mesa has a standing MRE, but upstream changed their release
>> cadence last year from a major release every 6 months to
>> less-major releases every 3 months..
> 
>> Now with trusty we're in a less-than-optimal situation that
>> support for Intel Broadwell will be completed in the next release
>> scheduled for May 30th, while trusty has 10.1 from late February.
>> Trying to backport support for BDW to 10.1 has proven to get out
>> of control pretty quick with 50+ commits and counting, and still
>> seeing brokenness not on master.
> 
>> So I'm asking if it would be possible to have an exception with
>> mesa, allowing a bigger update to land as SRU after sufficient
>> testing for regressions has been done on both T+1 and -proposed.
>> We have piglit as a test suite to spot obvious regressions, and
>> ways to gather wider testing from the community when it's looking
>> good enough from our side.
> 
>> 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.

> 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 :)

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



- -- 
t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTRvIVAAoJEMtwMWWoiYTcTNwP/20g5RGAqKzBUlZC6/aQTZ8m
bZSE87KcZKZG2dGAyRlxzFS7N8AZVgHcfVs0MHV6kGSi1TjtRFqa/ifvB1Bis2+F
WU5SSzFpiy0uuuvSPizfg2dgJypWRVApreDyiJDjncqAvUOo4XvRYXcYKwAfYysF
13SSUZ+ywJX8uhv+NCOERqY/QmKjouycDjXNNWOZDlx+l7+Ob09Y+8TBXY3DdpRh
TLf/PIOo0VjfRm3OTBkHNsLHY5lBkleiWEAkswd2hHsCFTb9SLesVAYEZUWIB7IT
pPzo9w2xrDvq8gj0eZA5Y+esEVuSe5+/3zuBuNTTfOUe2gLGySDDz+jaDQhlAx09
0TKzPqcIsQ26h/7pgteFRuJqY5CH8N0vVvoWzwmeHlJicjGQxT9AeKP6rOm3scA5
3oMfN4QvT8lY6GDlm7WwAfoHC5uEwU+VQ7bUK4yNpYdRSzsOe5uxQJ9Wk9PeRpwz
82ADhYe8WjqWXx5w49eMXWQc7FhglzaUoDxbAEEyUZOY0imIOSkZIVRSfIxfG5ha
yNZBAVVTwTg+yIZB1UMLmA2QXSRUIplaWHN3YgleE+iK5uqXXyLEWZ/uku2dxh+C
uPM6ZoipeZmSUeesnWAM+mQxBMREHSToa0BXLC/FGVohZ1cRaDjknBFGXq1FE7QO
fVVdZECp+DtSxiPuddO/
=TutR
-----END PGP SIGNATURE-----