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.