Governance revisited

[Robert Lunnon]

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