Mesa provisional MRE

[Rick Spencer]

Nicholas,

Could you please investigate if any coordination of rigorous manual
testing is needed to support this initiative? Thanks.

Cheers, Rick

On Mon, Jul 23, 2012 at 10:38 PM, Matt Zimmerman <mdz at ubuntu.com> wrote:
> 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
>
> --
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board