New subject: Governance revisited (Wineconf report)

24 Sep 2006


      ...
From: Kai Blin kai.blin@gmail.com
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
...
Frankly, all we really need is for Alexandre to write a 10-second 
reply to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow 
down the overall patch submission speed. Consider you have a 
patch that's just fine, but before you sent that, I sent in 
ten patches with C++ style comments. Alexandre would now have
to reply to ten patches with "No C++ style comments" before
processing your patch. Everybody reading wine-patches 
could point out what was wrong with my patches.
You must be kidding. Even in your somewhat convoluted example, it would be
fine to receive just a single notification "No C++ style comments" and I
really wouldn't care if the notification came from Alexandre or from someone
else on wine-patches. The reality is that a lot of patches (I haven't kept a
precise count, but I estimate about a third of my own patches) are dropped
silently, without any feedback at all.
I have absolutely no problem with a strict patch acceptance policy, designed
to keep the Wine quality high. Alexandre is amazingly smart and when he
tells me why a certain patch was rejected I'll usually agree with him and
even if I don't agree, I have enough confidence in him to accept his
judgement. But having your patches dropped silently is pretty annoying. The
usual response from the core Wine developers is "well, just resubmit". I
fail to see how this helps Alexandres productivity (or my own for that
matter). If patches weren't dropped silently the sequence of events would
be:
1) Submit patch
2) Alexandre looks at patch
3) Alexandre writes 10-second rejection reply
With the resubmit:
1) Submit patch
2) Alexandre looks at patch
3) Wait a week
4) Resubmit patch
5) Alexandre looks at patch again
6) Alexandre writes 10-second rejection reply
Seems to me this incurs extra work for Alexandre (number 5).
The patch processes isn't very transparant. For example, I submitted a patch
on 20 June 2006 to dlls/kernel/heap.c (www.winehq.org seems to be
unreachable for me at the moment so I can't give a URL to the message) to
fix a problem with the heap on Win64. This patch was silently dropped. On
July 21 a change very similar to what I submitted was committed but not
attributed to me. Now, either the commit was not based on my patch (in which
case someone else spent another 2-3 days (it was one of those problems where
a chain of out-of-buffer memory writes take place and you have to work your
way up the chain to find the root cause) on tracking down an already known
problem for which a fix was already available) or it was based on my patch
(in which case my patch shouldn't have been dropped and I should have been
given credit).
Like I said before, I have a lot of respect for Alexandres technical
abilities. But when I read comments in the Wineconf report about git:
"Developers might not like it, but Alexandre does so it's a success" (did I
mention I dislike git also???) and the inability of the Wine community to
set up a patch management system (so patches won't disappear into the big
void) because Alexandre refuses to use it if it won't work in Emacs I'm
starting to wonder if people realise that the developers don't work for
Alexandre. He's a great Benovelent Dictator on technical issues, but in my
opinion only a Dictator on patch process management.
Ge van Geldorp.

Re: Governance revisited (Wineconf report)