On 16.07.2014 06:16, Carl Worth wrote: > Michel Dänzer <mic...@daenzer.net> writes: > > 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.
[...] > 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. It does seem like that to me. > (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.) I'm fine with you asking the patch author or another developer of the affected subsystem for a backport if there is any conflict, however trivial. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev