Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)

Alex Henrie alexhenrie24 at
Fri Jun 19 18:34:51 CDT 2015

2015-06-18 2:08 GMT-06:00 Alexandre Julliard <julliard at>:
> So now I want to take a step back, and take the time to look at what we
> are doing wrong, and listen to new ideas. I'd like to encourage
> everyone, but especially people who are disgruntled or have given up
> hope that we'd ever change, to send (either in this thread or by private
> mail) their suggestions for what we should be doing differently, and how.

As a relatively new Wine developer, I submitted a UTF-7 implementation
copied from ReactOS, but it was rejected without explanation. After
some prodding, I was told that I needed to rewrite the code from
scratch.[2] Then, after I rewrote the patches, I was told to put the
implementation in kernel32 instead of libwine.[3] The next patchset was
ignored, but I finally got a couple of cryptic messages about a buffer
overflow and table-based tests.[4][5] Later I got more cryptic messages
about needing more tests, but again I was not told what needed to be
tested, just "think about it".[6][7] Finally I was told "this isn't
going anywhere",[9] "you have nowhere near enough tests"[10] and "if
you're too stupid to know what you're doing wrong then you shouldn't

The above process literally lasted from January to December 2012. After
that, I was so upset with the Wine project and AJ in particular that I
did not submit a single patch to Wine for more than a year.[12] When I
finally decided to try submitting the UTF-7 patches again in October
2014, I begged AJ for feedback and once again got nothing specific.[13]
In desperation, I turned to IRC and was invited to participate in Wine
Staging. They patiently provided specific, line-by-line feedback and
even helped rewrite the code in a couple of places. They also accepted
the code into their fork to get some real-world testing.[14] By the end
of November 2014 (less than two months later!) the patchset was
accepted into mainline Wine.[12]

Wine has been one of the worst, if not the worst, open source project I
have ever worked with. (I think it's a tie between Wine and Qt's
QSerialPort module, but that's another story.) My UTF-7 experience
illustrates exactly why we need Wine Staging or something like it:
Without the detailed feedback that the Wine Staging developers
provided, this feature would have never been accepted. Furthermore, I
would not have learned the tips and tricks that I needed to know to
write acceptable patches in the future.

The idea that all discussion and development needs to happen on
wine-devel and wine-patches in order to gain trust is BS. AJ was
unwilling to take more than a glance at the UTF-7 patches until they
had gone through probably a hundred iterations on GitHub and the
wine-staging IRC channel. In my experience, AJ is far more likely to
accept a patch done right the first time than a patch submitted 12
times because the submitter keeps finding problems with it.

Alexandre, the best thing you could do differently is to provide verbose
feedback on every patch. You have been working on Wine for a very long
time and what is obvious to you is not obvious to everyone else. If you
don't have time to write feedback yourself, ask another Wine developer
to do it. Ideally we would have a list of trusted advisors for each
program and DLL, people who are available to answer questions in their
areas of expertise. It would also be a good idea to notice new
developers, assign tutors to them, and have the tutors welcome the new
developers and offer to answer questions.

Please understand that I like Wine, I want to attract new Wine
developers, and I want to see it become the most popular Windows API
implementation. I hope you can take this email as constructive
criticism without it negatively affecting my Julliard Rank™ ;-)



More information about the wine-devel mailing list