On Thu Apr 25 19:10:22 2024 +0000, Elizabeth Figura wrote:
Adding a stub that doesn't actually help anything is basically just extra noise, and more code in the tree. In cases where someone is actively working on a proper implementation, it also often gets in their way. It may not be a big deal, but it's not exactly like there are zero disadvantages either.
For me a stubs that allow a programs to properly run further is a win-win situation as long as the stub stays on it's side.
The "In cases where someone is actively working on a proper implementation, it also often gets in their way." parts is not really a big deal as wine contributors already maintain patches on top of the latest code-base for multiples month already, adapting a patch on top of a stub is really not a big deal, I have dealt with far worse.
Those are not really a problem, sure it can take a few minutes, bit it's not a big deal, and almost everyone doing an MR to Wine has to deal with it already in some way.
If you still really want to go to the way of the "no stub" route, proper guidelines should be there in written form so there won't be 4th MR opened with the same stub, as most peoples would still think this would be useful to spend their time on this and are likely to open many more of the same MRs for nothing.
I really want to try and take a look on how to do a proper implementation though, as I have a sneaking suspicion it's not as complex to implement as it seems.