After having followed this thread for some time, I feel that there is an aspect that is often missed in the debate.
As I see it, it would appear that Wine contributors fall into essentially two camps. There are those who develop Wine for Wine's sake. This category includes the core developers, and others who just feel strongly about a particular aspect in order to improve it and perfect it. These people have time to spend developing and perfecting their code to meet the necessary high standards for acceptance and would not see the current system of governance to be an issue. These are the very people that would attend Wineconf and discuss the issue!
There is another category, however, and I suspect it is the larger of the two. Some people simply need to quickly fix an aspect of Wine in order simply to get an application working. These individuals, a category into which I fall, are driven by a very different motive. To take an example, my (very) small contribution to Wine was driven by the need to get a commercial ECAD application running, so that I could continue to use the application as a production tool on a production system in order to continue to function as an electronics engineer. In my case, I am also a software developer who believes in feeding useful fixes back to the community, so I used up some of my valuable free time and got the patch accepted. It took approximately three times longer to get the patch accepted than it did to fix the problem in the first place!
I persevered, but I wonder how many other individuals who fall into this category would do the same? Another contractor driven purely by commercial pressures may have just got it working and kept the fix in their own tree. Such people do not have the free time or the inclination to go through the numerous iterations to get the patch accepted. Free time is a rare commodity these days, and most software developers will have other projects. These are not the people who would attend Wineconf and whose opinions can only be solicited through other means. How many Wine trees are there out there containing useful small fixes that see the light of day outside of the developers's box, simply because they do not have the time to struggle through the QA system. A number of these patches could be being lost to the community.
How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel.
The quality of Wine is important, and a workable QA system is very necessary. However there should be a mechanism to enable widespread dissemination of contributions that for various reasons do not merit direct inclusion in the tree at that time and for which the developer has neither the time nor the inclination to do battle with the QA system.
Just my thoughts.
John. Vijay Kiran Kamuju wrote:
Some kinda patch management system would help. I think like bugzilla.
On 9/20/06, Jeremy White jwhite@winehq.org wrote:
Wine works fine as-is in my opinion ;)
Which you are entitled to, but my opinion happens to differ.
Whether the wine
core source has all the patches, (Which it doesn't - many, but not
all) isn't
relevant, it's the process that they go through that I believe could
improve.
For the record, Governance is something we often spend a chunk of time on at each Wine conference.
Brian has written a nice summary of Wineconf on WWN (thanks Brian!), including a reprise of the talk on governance.
Being insufferably long winded, and feeling the need to create a complete record, I would add a few things to what Brian wrote.
First, I think there was clear and essentially unanimous agreement that the current high standards for quality were a Good Thing (TM), including the Holy Order of Writing Conformance Tests.
Second, I think we had fairly clear agreement that so long as he can handle it, it is most efficient to have Alexandre as the sole maintainer. Obviously, the more help he gets from component maintainers (e.g. Mike/MSI, Rob/COM), the better.
Third, I think there was clear agreement that Alexandre is often a Royal Pain In the Ass (RPITA). He ignores patches, responds tersely, and sometimes delivers the occassional kiss of death: "I can't tell you what to change, but your patch is wrong."
However, we, the assembled 30 or so of the most core Wine developers, could not think of a single case where Alexandre had been proven wrong. Nor could we think of a single instance when he had failed to be persuaded by reasonable argument; making a rather compelling case that he is generally right.
We also talk, from time to time, about building some sort of patch tracking system to allow for better management of patches. Something like a 'ticket' system, so people could see the status of their email, whether or not it had been reviewed, etc, etc. I think there is some sense that this might be useful, but it's a sufficiently complex problem, and it has to be written in emacs, that we always defer it for the future.
So I think the strong (if not unamimous) consensus was to continue on as we are, but make an effort to provide an 'ambassador' program of some kind, particularly around folks that are new to Wine.
If you have a specific concrete suggestion for change, this would be a fine time to put it forward.
But if your proposal is largely: "Alexandre should accept more patches", I think you'll find that none of the core Wine developers will support you in that, so it's not worth the effort, at least not in this venue.
Cheers,
Jeremy