Michel Dänzer <mic...@daenzer.net> writes: >> configurations are. All I need is something along the lines of: >> >> "The radeon team is OK with releasing commit <foo>" ... [snip of the rest of my proposal]
> This sounds good, but... Good! Thanks for reading this and giving me some feedback. >> 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. Yes. I do want to give the driver maintainers a lot of discretion. They are already the people who are doing the proposal of which changes should be backported. Quite frankly, my real concern with all of this is not that the driver maintainers will propose something bad, but that I will inadvertently botch something while cherry-picking or merging a conflict, etc. that I won't be able to notice in my touch testing. > 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. Previously, for each stable release, I was doing piglit testing against the hardware driver for my personal laptop. My hope was that that would give at least some coverage for any mesa-core changes. With the current release cycle, I've expanded that testing to also include piglit runs against swrast (in both dri and gallium flavors). I hope that that will give us sufficient confidence in non-driver-specific changes. With this additional testing, it's sufficiently time-intensive that I don't plan to repeat it in a single cycle, (I'm performing that testing before pushing out a proposed branch like I did yesterday). That's why my email yesterday said I could still accept driver-specific changes, (but any core changes will have to wait for the next release). > It's unlikely that any individual or organization can test all > affected setups in advance. I agree. And I won't require that. All I want is what I said above: "We're OK with releasing commit <foo>" From a reasonably representative of each driver team. I'm not going to ask for documentation to backup that statement, (no piglit reports or anything else). So every driver team can come up with their own criteria for comfort level. If you're happy to continue to just defer to me (or any other stable-release manager), then all I'm asking for is one quick email each release to give your OK. If driver teams want to do some actual testing, then this new process gives them time to do that testing and a way to communicate those results prior to release. And I think that's the most-important change here. I'm committing to providing a 3-day window in which testing can be performed prior to each stable release. > We at AMD are working towards having such regular testing, but we're not > quite there yet, nor do we have an exact schedule yet for when we will > be. It's great that you're working toward it. I think that's a valuable goal that every driver team should work toward. But my proposal was not intended to make that a requirement. You can continue to get your commits in with no additional testing on your part, by just affirming for each release that you're OK with what the stable-branch maintainer has put together. When I phrase things that way, does it seem more reasonable to you? And if this feels like a more bureaucratic means for doing nothing effectually different than what we did before, please humor me. I think it can help reduce some psychological pressure for the release maintainer. (Maybe I'm just a wimp, but it's been tough at times to trust myself to resolve conflicts in code that I know I don't have any way to test. I do ask for help if the conflict looks really messy. But I don't like to bother people for things that look trivial. And even the trivial, manual conflict resolution can give me misgivings that I might be breaking the release.) -Carl
pgpN7MeBSwt6B.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev