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 - [EMAIL PROTECTED]