-----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----- -- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
