Governance revisited (Wineconf report)
wine at troy.rollo.name
Sun Sep 24 18:56:28 CDT 2006
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.
> 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
More information about the wine-devel