[Mesa-dev] A proposal for new testing requirements for stable releases

Ilia Mirkin imirkin at alum.mit.edu
Tue Jul 15 02:50:54 PDT 2014


On Tue, Jul 15, 2014 at 2:18 AM, Michel Dänzer <michel at daenzer.net> wrote:
> On 09.07.2014 08:10, Carl Worth wrote:
>>
>>   3. I'd like to receive a testing report from each driver team
>>
>>       This is the meat of my proposal. I'm requesting that each driver
>>       team designate one (or more) people that will be responsible for
>>       running (or collecting) tests for each release-candidate and
>>       reporting the results to me.
>>
>>       With a new release-candidate pushed by the end of the day on
>>       Monday, and me starting the actual release work on Friday, that
>>       gives 72 hours for each team to perform testing.
>>
>>       I'm happy to let each driver team decide its own testing
>>       strategy. I would hope it would be based on running piglit
>>       across a set of "interesting" hardware configurations, (and
>>       augmenting piglit as necessary as bug fixes are performed). But
>>       I do not plan to be involved in the specification of what those
>>       configurations are. All I need is something along the lines of:
>>
>>               "The radeon team is OK with releasing commit <foo>"
>>
>>       sent to me before the scheduled day of the release.
>>
>>       Obviously, any negative report from any team can trigger changes
>>       to the patches to be included in the release.
>
> This sounds good, but...
>
>>       And in order to put some teeth into this scheme:
>>
>>       I propose that on the day of the release, the release manager
>>       drop all driver-specific patches for any driver for which the
>>       driver team has not provided an affirmative testing report.
>
> ... this seems a bit harsh.
>
> A lot of backported fixes are specific to one driver and have zero
> impact on anything else. Surely it should be up to the discretion of the
> driver maintainers whether or not such changes should be backported.
>
> OTOH, who's supposed to give that sort of OK for changes to say st/mesa
> or Mesa core? The former may affect all Gallium based drivers, the
> latter basically anything. It's unlikely that any individual or
> organization can test all affected setups in advance.

Perhaps that should have read s/testing//? I think all he's looking
for is a "yes" from each driver team with changes in stable. This can
be derived from your supreme confidence in your mesa-stable tagging
(and Carl's super-human cherry-picking), or just seeing if the thing
builds with your driver, or actually running it on any hw you deem
necessary.

FTR, I believe I'm the one who suggested adding teeth to this since I
felt that no one would actually do any checking unless there was some
reason to. The mesa/core and mesa/st changes get a free ride since (a)
Carl can test them on his setup via soft/llvmpipe and (b) the shared
responsibility makes it awkward.

Cheers,

  -ilia


More information about the mesa-dev mailing list