Governance revisited

[Mike McCormack]

>>Since you know better, how about maintaining your own Wine tree and
>>showing us how it's done?
> 
> Self evidently thats what I have to do until some core functionality patches 
> find their way into WineHQ wine. It's not particularly hard, but it is time 
> consuming to manage merge conflicts.

It's very easy to say Alexandre should do this or Alexandre shouldn't do 
that when you haven't put yourself in his shoes, and tried to do what 
he's doing.

Fact is, it's a difficult and time consuming job.  By reviewing your 
patches, Alexandre is doing you and everybody else in the Wine community 
a service.

Secondly, patches that get no response are not "rejected".  You should 
consider them as "not obviously correct" rather than incorrect.  The 
problem may be simply that they're too complex to review and reply to in 
a short amount of time.

I don't think a web based patch tracking system will work for reasons 
pointed out by Jeremy in another mail, and that it would be very 
difficult to integrate it with Alexandre's work flow without wasting 
more of his time.

So I have some possible ways to enhance the current procedures:

1) When somebody has sent a patch to wine-patches that hasn't been 
applied for a few days, write to wine-devel and request that others 
review it.

2) Enter into bugzilla the *problem* that your patch addresses (not the 
patch itself), and attach the patch to the bug.

These may not be to your liking, but if they're not, fork Wine and 
maintain your own public Wine tree, as Alexandre's tree is maintained 
using Alexandre's methods.

Mike