Suggestions for improvement of the emulator

[Francois Gouget]

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.


[...]
> Functionality,
> Portability,
> Precision - EG precise windows like behaviour
> Form.
> Implementation.

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 
top.

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 
platform.

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 
stagnates.

So my own list would look something like this:

  Windows Conformance (was Precision)
  Portability
  Functionality
  Maintainability     (was Implementation)
  Features
  Formatting

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* 
*consensual* one.


> 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