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

Jeremy White jwhite at codeweavers.com
Mon Jun 15 15:29:10 CDT 2015


> I'll try to respond to this email with my recollections, and my sense of
> the problem, and see if we can think of any constructive way to improve.


This is a long email; I'm trying to put down as much of the history as I
recall, in an attempt to have it in written, archived format.  I'm also
trying to express my understanding of the current points of pain.

Disclaimer:  these are my opinions, not those of Alexandre.  I ascribe
motivations to him that I think are essentially correct, but I rely on
him to correct me where I've got it wrong.

First, we always seem to agree that Alexandre is fscking smart; that he
is better qualified than anyone we know to judge what comprises good
code, and what will work well with Wine.

Further, we generally settle in to accepting the 'benevolent
dictatorship'; that it is efficient to have him as the sole maintainer,
and that he is sufficiently smart, and his (!Julliard)Rank is
sufficiently high that we trust him to do it well.

Second, we often explore whether or not Alexandre has a bandwidth
problem; that is, if he just had more free time, could he respond more
ably.  (The "he's not an asshole, he's just swamped" theory <grin>). He
assures us time and time again that is not the case - that he handles
the work load okay, and he is just an asshole <truly evil grin> [1].

As a subset, we often talk about whether or not there are tools that
would better help him; the current patch page is, as far as we know,
sufficient for him, although he could really use a stronger WineTestBot.

Then, in addition to that, Alexandre was burned badly in the early days
of Wine by taking in patches that were useful to a user, but were poorly
formed.  Those patches often went on to cause later problems in Wine,
and promises that "I'll fix it later" often didn't materialize.  By
contrast, having the nagging state of:  "This is ridiculous!  There is a
patch *here* that fixes *obviously important problem* there, why the
hell isn't it in Wine" has, through the years, served to eventually get
the right patches into Wine.  (One famous example was the xinput2 patch
set, and the current pulse and command stream patches are also clear
cases of this phenomenon).

Further, it is getting increasingly rare that a valuable patch is
isolated.  He has much more relaxed standards for accepting code into
obscure_and_completely_unimplemented.dll than for accepting wine server
or ntdll changes.  And changes to key areas have a nasty habit of
causing subtle problems elsewhere, or in the future.

Thus, he has a fairly strong incentive to hold out for the very best
code he can get, and history has proven that if he holds out for higher
quality code, he can eventually get it into Wine.

Next, as Alexandre has recently articulated in this thread, he has a
process he likes Wine contributors to follow to establish trust with
him, and a persons trust (humorously known as JulliardRank) is
absolutely critical to his acceptance of his patch.

He has some personality quirks; he is clearly striving to hold the world
record in information density; trying to use the fewest words possible
(where as I strive for the opposite <grin>).  That sometimes comes
across as rude or abrupt, and is (usually) not intended as such.  He's
also generally content with the 'bug-me-if-I-dropped-your-patch' method,
which often surprises people.

I think Alexandre also has a hard time understanding some people's
mental gaps; what is obvious to him, or something he thinks should be
obvious to you, will not become obvious to you, no matter how long you
stare at his words (or lack of words :-/).

And then, rightly or wrongly, the amount of energy Alexandre is willing
to spend on someones patch is inversely proportional to their trust
rank.  Gradually, over time, if you cannot improve that rank, he is
willing to to invest less and less in helping you get that patch in.

That's frustrating, because he is often the only real gatekeeper.  There
is no appeals process, and often no other developer has constructive
advice to offer.

I think Michael touched on the most frustrating possible outcome:  to be
a developer, with evidence that you're smart and capable in your own
right, with a patch that you worked day and night on *that solves a real
problem*.  Now this patch looks right to you, even after hours of study,
and it clearly solves a user problem, and it passes the regression
tests.  Then you send it in...and it's ignored, or it is rejected
because Alexandre 'is not convinced'.

It hurts; it pisses you off; you feel trapped with no way forward.  That
sucks.

Of course, there are two divergent narratives:  one is that of a good,
valuable developer, being wrongly discouraged.  The second is a
developer trying to help, but not really able or willing to spend the
time to create quality code.  We want to invest time in the first
developer, but not necessarily the second, and it's very difficult to
distinguish between the two.  (And there are sub cases; a one shot
developer who finds + fixes a bug, throws us her patch, but then doesn't
want to bother hanging around to see the patch through.  It's probably
useful to capture the knowledge in that patch, and maybe even have a
different developer respin it and get it in, much as Alexandre is
resistant to that).

We have, several times in the past, resolved to try to have ambassadors
to help newbies.  People to try to help new contributors navigate this
process, and to feel encouraged to have the patience and gumption to see
their patch through.  I think there is value in that effort, but it
clearly has not been enough, given the current frustration levels.

The only other thing on this topic that I can recall is that there are
parts of the process that were obvious to Alexandre, and not always to
others.  The concept of JulliardRank; the concept that bugging him about
patches is perfectly fine.  But I believe that all of that was 'fixed'
by amending the Wiki.  It may be that it's not as 'fixed' as we'd like :-/.

At any rate, sorry for the long email; just trying to be complete.

If I've misunderstood frustrations or points of pain, or if there are
ideas for changes, please chime in.

Cheers,

Jeremy

[1]  The dirty secret, as much as he will insist otherwise, is that he's
actually a pretty nice guy.  The level of vitriol on the Wine mailing
list is a fraction of that produced on many other projects, and I think
Alexandre really does not like hurting peoples feelings.  But the point
is that he's willing to be the asshole if that's what it takes to ensure
the best result for Wine.  If you think about it, that's a pretty
gracious gift.



More information about the wine-devel mailing list