Mesa provisional MRE

[Matt Zimmerman]

We discussed this briefly at today's TB meeting, and agreed that this makes
sense.  As long as the regression tests get run on every update before it
leaves -proposed, that's what matters.  If that can't be automated yet, then
it needs to be agreed as policy that someone will do it.

On Thu, Jul 12, 2012 at 11:07:40PM +1000, Christopher James Halse Rogers wrote:
> The X team and I would like to get a MRE for mesa stable point releases.
> As a first crack at this, I'm asking for a provisional MRE for mesa
> 8.0.3 in precise-updates.
> 
> Mesa releases micro releases from its stable branch; 8.0.3 is the third
> of these, there will be 8.0.4 shortly. The stable branch generally
> doesn't see further updates after the next major release, but some good
> fixes tend to be accumulated until then.
> 
> Mesa is a bit of a special beast; it doesn't have in-source regression
> tests but it *does* have an extensive regression and conformance suite
> called piglit. Also, since Mesa touches hardware, running this
> regression suite as a part of the build on the buildds does not make
> sense. Instead I propose that we run piglit on the QA infrastructure -
> there's a wide variety of graphical hardware in there, so we can be
> reasonably confident that if piglit does not regress on the QA hardware
> then it will not regress elsewhere. (Bryce has already run piglit
> against 8.0.3 on all his hardware without regression)
> 
> In the past we've failed to pick up any but the simplest bugfixes for
> mesa, both due to concerns about regressions and because all but the
> simplest fixes appear quite complex, making the SRU team justifiably
> nervous. I hope that piglit on the QA machines can sooth our concerns
> about regressions, and that the MRE can make it easier for the SRU team
> to accept.



> -- 
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board


-- 
 - mdz