Suggestions for improvement of the emulator
fgouget at free.fr
Wed Sep 7 19:11:36 CDT 2005
On Thu, 8 Sep 2005, Robert Lunnon wrote:
> The issue isn't about Alexandre, it's about a governance model that revolves
> around the opinion of a single person and whether the difficulty of having a
> patch moved forward is inhibiting the take up of developers.
I think this governance model can work as long as the 'gardian' of the
source has the required competence, experience and vision.
And I think Alexandre has all these qualities. Despite you saying this
is not about Alexandre you must be of a differing opinion since you are
not happy with the current situation as your arguments about the
'Solaris core functionality patches' show.
But an hypothetical committee aproach won't help an hypothetical set of
patches get through unless a solid majority of the committee is in favor
of that set of patches.
> Interestingly even codeweavers has such patches that Jeremy White
> terms "Proprietary Advantage".
Yes CrossOver has ugly application-specific hacks that happen to help
one of the supported applications but may well break a 100 non-supported
applications. And yes Alexandre won't let CodeWeavers commit these
patches to Wine. And yes, he is right to reject such patches since they
are not correct (i.e. don't conform to Windows behavior).
> I think you miss my point, this sort of code gets into Wine every day. Wine is
> already very linux centric and possibly getting more so.
And what practical measure are you proposing to avoid this?
I don't see how a multi-committer model is going to help. All you need
is one Linux-using committer to commit a patch to break things for all
others. The only way to avoid this would be to require approval by all
committers before a patch actually gets committed which does not seem
practical or likely to speed up acceptance of patches.
> Precision - EG precise windows like behaviour
In the following I'll assume Functionality to mean 'percentage of
working Windows applications'. The more traditional interpretation would
be to equate it with features but that's probably not what you meant.
Either way, trading precision for more functionality is not a good move.
It means introducing bugs, in order to hide other bugs so now you have
two set of bugs. Except the hidden bugs will now bite you when you don't
expect and without you realising what has bitten you which makes
debugging and thus progress harder. So 'Precision' should be at the very
It's also my opinion that portability should be before functionality.
That is functionality can be added only so long as it does not prevent
portability. That's why Wine has all these autoconf checks and even
runtime checks so one binary can work on most systems inside a given
And if I'm right to understand Implementation to mean Maintainability,
and Form to refer to the indentation and so on, then Maintainability
should come before Formatting. That's not to say I'm not annoyed by some
of the weird formatting of some source files but maintainability has
more of an impact on the ability to make the project move forward (and
one can also argue that the nastiest forms formatting are part of the
maintainability issue anyway so that all that remains to formatting is
the minor issues).
I'd add features to the list, as in various options, bells and whisles,
etc. This should go after Maintainability. That's because while bells
and whisles are nice, killing maintainability will ensure the project
So my own list would look something like this:
Windows Conformance (was Precision)
Maintainability (was Implementation)
I think it matches the Wine project priorities.
> Remember the project has no inherent right to demand a participant
> change a patch,
This is true. Just as true as the following:
The participant as no right to demand that the project accept his patch.
The relationship between a project and a volunteer is a *mutually*
> it will only succeed in this endeavour if it can command the loyalty
> of the participants. Loyalty comes from the value the project places
> on the individual participant.
Indiscriminately accepting patches is not a workable way for a project
to move forward. Building a project like Wine is like building a wall
where each volunteer contributes one or more 'bricks'. Now if you start
accepting not just genuine bricks but also pieces of wood, shoe boxes,
lego bricks, plastic boxes and any other material brought by the
volunteers your wall is soon going to collapse. And that will set the
whole project back, possibly forcing a very costly redesign, throwing
away much code, etc.
Indiscriminately accepting patches will not buy you loyalty. Wisdom in
choosing which patches should go in and which need to be reworked will
buy you respect and loyalty.
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
Linux: the choice of a GNU generation
More information about the wine-devel