Sebastian Lackner sebastian@fds-team.de writes:
I understand your concerns, but from my understanding you also don't want patches which for example temporarily introduce bugs, just to fix them shortly afterwards.
Qian Hongs original patch is available here: https://bugs.wine-staging.com/attachment.cgi?id=289&action=diff
The original version lacked proper parameter checking, and also didn't clear the full buffer. To be honest, there isn't really much left from the original version, but I still think its fair to give attribution to Qian. We were working together on fixing various msys2 bugs, and this was one of them.
Do you have a better suggestion how to deal with such situations in the future? In case of active contributors I can ask them to fix the most critical bugs of course, and afterwards put my patch on top of it. But what about inactive contributors? What about series of patches where the initial idea turned out to be wrong, and it was later fixed by a different contributor on top of the existing code?
What should happen is that Qian would submit a patch (to wine-patches, where everybody can see it) then if you see something wrong with it, instead of going ahead and making changes yourself, you tell Qian about it (and CC wine-devel so that we are all aware of what's going on), and let him address the issues and resubmit the patch. Repeat until the patch is good enough.
The process of having people fix their own patch is important. Not only it lets them learn from their mistakes, it also enables us to see where they are struggling, how they improve, how much they care, and builds the trust necessary to get patches approved. The process is at least as important as the final result.
That's my issue with wine-staging: it's trying to shortcut the process on the idea that if the final patch is OK, it doesn't matter how you got there. But to me, it does very much matter.