On 10.06.2015 11:00, Sebastian Lackner wrote:
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.
See, but there's no way to know that when you submit a patch and not Qian.
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?
I think the best way is to have original author submitting it in any case, after it's submitted you can help improving it right here on wine-devel, that everyone reads daily. Getting patch accepted is one goal, but not the only; educational value of getting a review is huge, what I believe we want (and author should too I think) is to make next patches from this author increasingly better, to the point when you don't have to improve anything.
I think it would be really nice to define a bit more exactly what is allowed/ preferred here and what not, especially when thinking about long standing problems like the inclusion of the Pulseaudio patchset.
That's different and should be separated in my opinion.
P.S. sorry if I disrupted this conversation.