bobl at optushome.com.au
Sat Sep 16 17:09:24 CDT 2006
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.
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...
The issue is not code, It's governance. Governance to establish balance,
balance between beauty and function.
More information about the wine-devel