ntdll: Improve stub of NtQueryEaFile.

Sebastian Lackner sebastian at fds-team.de
Wed Jun 10 09:39:03 CDT 2015

On 10.06.2015 10:38, Alexandre Julliard wrote:
> 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.

Hello Alexandre,

It is a bit unrealistic that from now on everyone is going to submit their
raw draft patches to wine-patches, although they need additional work.

Moreover, as mentioned in the first mail, we were working together on
fixing various msys2 bugs. If Qian would have preferred to tackle this
problem himself, I would have given him some additional time of course,
before I start with my own attempt. @Qian: Please correct me if I'm wrong,
and you feel like I'm stealing your work.

> 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.

I have to admit that the whole idea sounds nice, but based on my experience
it doesn't really work very well. Such a method only works when every patch
gets detailed and fair feedback, which is not the case at the moment. A lot
of patches are not reviewed at all.
I can perfectly understand that a lot of longtime wine developers don't want
to mess around with patches of a very low quality, but what exactly should
people learn from being ignored?

For others the feedback is sometimes a bit too strict if you ask me. Trying
to submit an unfinished patch on the mailing list, will not result in an
answer "let us work together to get this upstream", but often a kinda harsh
and almost unfriendly answer, which leaves the impression that noone really
cares about it. Also, in situations where it is not reasonable to ask for
another iteration, or where the author has given up, it should be possible
to integrate the last available version, to allow others to continue to work
on it, which is also not the case right now.

Regarding the concern that Wine Staging makes it impossible to follow the
process how the patches were created - do we know how many iterations
developers do in their private repositories, before they finally submit it?
Do we know how often people ask for feedback privately, before sending their
patch? Obviously not. If there is a fear that upstream developers miss
anything important, we should think about integrating Wine Staging a bit
better into the upstream concept of submitting patches, instead of blaming it
for everything. Wine Staging is not the problem, its an attempt to solve it,
and only future will be able to tell if its the right approach.

Best regards,

More information about the wine-devel mailing list