On Sun, Apr 24, 2022 at 5:26 AM Alexandre Julliard julliard@winehq.org wrote:
Austin English austinenglish@gmail.com writes:
At the same time, I agree of course that just the contributor's desire to work on something is enough to consider submitted work. For this patch what kind of feedback would you expect?
I think the feedback/review, in general, has been fair/valid. I am disagreeing in how explicit Wine is being, as a project, for testing patches before submitting upstream.
The issue is not testing the patch, it's demonstrating that there's a need for it in the first place.
Can we clarify what is needed to demonstrate that this patch is needed?
I.e., it would be helpful, particularly to new/infrequent developers, to be able to note when it's necessary for a developer to explicitly test a patch. I.e., if it involves IE internals rather than win32, if the API is not on MSDN, etc.
That has been the policy forever, we only implement things that are actually used by a real application. There are tons of things in the Windows API that are used only internally, or no longer relevant, or simply never used at all. Adding them only increases our workload for no benefit.
Yes, I'm aware, having been bit by it a few times myself, but thanks for the reminder ;).