Governance revisited

Marcus Meissner marcus at jet.franken.de
Sun Sep 17 06:48:11 CDT 2006


On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
> I note the recent flamefest, where some of this list seared yet another 
> contributor (Roland Kaeser)
> 
> Since this particular very old, very shrivelled chestnut. is one of my 
> personal favourites (thanks to Colin Wright for the chestnut thing...). I'd 
> like to repeat my observations about this. Feel free to flame away since I 
> have donned my asbestos suit and have long since decided my viewpoint.
> 
> The problem is that code gets rejected that is *** NOT *** Hacky because there 
> is a, single point of review - a single opinion of what constitutes a hack, 
> and no appeal process. For example I once submitted code to implement cpu.c 
> using the x86 cpuid instruction directly on all x86 platforms. This was NO 
> hack. But the code was rejected. This code replaces the OS specific code for 
> several x86 cases with generic code. The way I see it this code removes hacks 
> (since I consider any OS specific code fragment a hack). This just shows that 
> opinions differ about what a hack is. This code now sits in my patch-kit, 
> never to see the light of day on wine-hq, but happily runs in every copy of 
> wine for Solaris for the last 4 years with ZERO issues. 

Well, regular WINE no longer needs this patch, since it has been fixed 
differently.

In fact according to Alexandre everyone of your patches is now done in
mainline, so your patch set is no longer necessary.

> No hacks should not be an objective, by my definition wine already has more  
> hacks than just about any other open source package out there. Linuxisms 
> continue to contaminate wine every  month (I can vouch for it). What we need 
> is management, balance between function and beauty delivered by peer review. 
> Necessary functional hacks should be allowed unless they have severe 
> side-effects. Even application specific work-arounds  can be permitted if the 
> work around adds significant functionality per the objectives of the project, 
> the scope of the work-around is suitably confined, and assuming the code can 
> be maintained over time. 
> 
> Wine needs process...

Wine works fine as-is in my opinion ;)

Ciao, Marcus



More information about the wine-devel mailing list