https://bugs.winehq.org/show_bug.cgi?id=55859
--- Comment #22 from Zeb Figura z.figura12@gmail.com --- (In reply to Alex Henrie from comment #21)
(In reply to Zeb Figura from comment #20)
(In reply to Alex Henrie from comment #19)
Rebase the merge request every month until it gets more attention.
No, please don't do that. That wastes CI resources and doesn't help anything.
If the MR is not updated, people will think that it has been abandoned and that no one cares about it anymore. And if it is updated in a way that does not rerun the tests, people will be concerned that tests that were written after the patch was written might start to fail when the patch is merged. In my humble opinion, both of those considerations are worth more than than the cost to the CI server, which is probably not much if the submitter waits a full month between each rebase. However, if the Wine project leadership wants Fabian and me to stop rebasing when it's not strictly necessary, then we'll just have to defer to your preferences.
Commenting on the merge request is probably a better way to achieve that goal.
More to the point, what can we take off of your plate to give you (or whoever the appropriate reviewer might be) time to review the patch and identify specific action items to move it forward?
I should apologize for my silence, I've mostly had the feeling that it should be possible to create a better stub.
Somewhat relatedly, what this family of functions is probably supposed to do is actually functionality that I've implemented locally, but in a different place, and should probably be moved here. That would avoid the need to even stub it at all.
I've mostly wanted to find the time to look into the function and see if I could figure it out in more detail, or actualize my implementation. I haven't actually said anything, partly because of this, and partly because "I think it should be possible to do better" isn't really helpful either, inasmuch as you are looking for specific action items.
I actually am actively looking into it right now; I've identified the purpose of the "flags" parameter (it's actually the processor architecture) and I have some tests for find/add/delete that are passing on Windows 7, but I'm still trying to figure out how to make them pass on 8 and 10, and they need some cleaning up, and then I'll need to adjust my implementation to fit inside setupapi.