Governance revisited (Wineconf report)

[Troy Rollo]

On Saturday 23 September 2006 11:39, Steven Edwards wrote:

>  As it stands right now the only reason technically
> good patches have been rejected is due to concerns over reverse engineering
> in another project.

I don't see the difference between rejection and "I won't put this in yet 
because I want to wait and see if X happens" where X is something that might 
take I long time. This has been known to happen. In a couple of cases I (or 
somebody working for me) have had this response after going through extensive 
discussion about how a thing should be done and then doing it that way. 
Essentially, sometimes Alexandre has ideas about how something should be done 
but is unwilling to commit. Sometimes he will have a suggestion as to how 
something should be done and then change his mind later (reflecting the 
reality that nobody is right *all* of the time).

> The developers have the right to disagree and we do quite often. However we
> have mob rule with a benevolent despot and none of us really like to work
> any other way. If the project demographics change and the developers decide
> they don't like the system then, once again, we would change.

The present system is self-reinforcing since people who run into significant 
problems will slow down on (or cease) their contributions.

Things would be much better if there were a system in place that ensured every 
patch that didn't get in resulted in feedback. Right now it seems only a tiny 
fraction of patches that don't go in result in feedback. Contributors 
shouldn't feel like they have to go around begging for feedback every time a 
patch is not applied. Having a suitable system in place would also prevent 
the "oops, missed that one, please resubmit" situation.

As things stand it actually involves less effort per patch to maintain a 
separate branch than to go through the begging-for-feedback process.

> Our 
> governance is ultimately that Alexandre rules at the consent of the
> governed and while it can suck to be in the minority of mob rule from time
> to time, the mob agrees to keep Alexandre as the benevolent dictator for
> life. I for one hope this never changes as it seems to be the best system
> for making stable FOSS software.

Yes, kind of. It would suck to establish a full-scale bureaucracy that might 
actually slow things down. On the other hand there seems to be a culture here 
that there is only One True Answer to every problem - in reality two people 
may disagree about the way a thing should be done and both be equally right.

> etc. As a Wine developer I do not develop for the users. I develop for my
> own needs and really don't care what the users have to say other than how
> it relates to my job.

Bob and I are in somewhat different situations, given that we are developing 
for customers and both have customers using Winelib apps. I *was* also making 
some contributions for non work-related stuff but don't do that anymore, in 
large part because it's such a PITA to do so.

I suspect there is also a significant difference between contributions 
extending Winelib functionality and contributions on Win32 compatibility. For 
Winelib functionality there is often a larger design element involved than 
Win32 were you are just trying to find the best way to implement the same 
functionality Windows has.

-- 
Troy Rollo - wine at troy.rollo.name