Suggestions for improvement of the emulator

[Troy Rollo]

On Thu, 8 Sep 2005 04:42, Jeremy White wrote:

> But the best way to persuade me (and others) of that is to highlight
> the patches.  Show me patches you've submitted, along
> with arguments for them, and persuade me that he has
> been wrong to refuse them.

I said I wouldn't comment further, but I think several people have completely 
missed the point.

The issue is not that patches get rejected. It is that in many cases there are 
many reasonable ways to implement any given thing, but only a subset of those 
will be accepted. This is particularly the case with any significant new 
development, and "do it the way windows does it" is not always the right 
answer, particularly if what you are implementing is Winelib related since 
Alexandre actually prefers things not directly dependent on Windows be 
"right" within his interpretation of "right" rather than consistent with what 
would be done if Microsoft were implementing the thing. *Nobody* but the 
person approving commits is going to be able to give reliable guidance on 
which of several different approaches to take in order to produce work that 
will be committed, except in the most trivial case. Where that is limited to 
one person, there are inherent limits to scalability.

Scalability is not boolean. You do not reach a particular point where it 
breaks, rather things deteriorate gradually at first, then at an increasing 
rate as you approach breaking point. As things deteriorate, the value 
perceived by new developers decreases.

Isolated volunteers who have already committed to the project and are prepared 
to accept these limitations are unlikely to see the problem. Volunteers who 
are not prepared to accept the limitations are unlikely to be heard at all 
because they will drop Wine and move on to other projects. Codeweavers tends 
to fall more into the dedicated volunteer category because that is where it 
sources its developers. Neither Robert nor I are entirely volunteers though, 
so there are other factors operating on our decisions.

If I were solely a volunteer I would have ceased contributing to Wine since I 
have other projects I can be more productive on, and Robert has indicated his 
similar position. That would be my position even though I believe that aside 
from the Linux kernel, Wine is the single most strategically important open 
source software development project in existence.

It should not make us happy that other projects are as bad or worse at scaling  
if there is the possibility of improvement. However if other projects of 
similar size (or greater) are better, then that is likely demonstrative of 
the possibility of improvement.

Is progress good? Yes. Could it be better? That is the question. Would this 
require a sacrifice to quality? Only if you believe Alexandre is infallible 
and that nobody else could competently shoulder any of his load - which 
raises the question of what happens if he encounters the proverbial bus. But 
nobody is infallible - not you, not I, not Alexandre. And I believe there are 
a number of people around here who could competently shoulder some of the 
load. That does not mean they have to make the *same* decision as Alexandre, 
just that they need to be making decisions that are within a legitimate range 
an acceptable proportion of the time.

Allow me to remind people of the original trigger for this discussion.

On Mon, 5 Sep 2005 06:24, Alex Tanner wrote:
> If all the companies worked together on a
> single WinXP-Pro-emulating flavour of Wine, the
> manpower problem would be solved.

I responded:
>Not really. Firstly there is not (yet) enough commercial interest in 
>contributing to Wine development to provide the manpower, although that is 
>changing.

>Secondly, even if there were sufficient manpower, the way the Wine project is 
>currently structured would prevent the manpower from being used efficiently. 

On Mon, 5 Sep 2005 20:30, Francois Gouget wrote:

> What makes you say that?
> What would need changing to efficiently accomodate *more* developpers?
(emphasis mine)

I responded, inter alia:
>This is all relevant, of course, only *if* significant expansion of the pool 
>of developers is a desirable goal.