On Tue, Jul 15, 2014 at 2:18 AM, Michel Dänzer <mic...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
