Governance revisited (Wineconf report)

[Dr J A Gow]

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 at 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
>>
>>
>>
> 
> 
> 
>