On Sunday 17 September 2006 21:48, Marcus Meissner wrote: > 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 ;)
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. Bob
