[Mesa-stable] [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-stable
mailing list