Suggestions for improvement of the emulator
wine at troy.rollo.name
Wed Sep 7 20:02:56 CDT 2005
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.
>Not really. Firstly there is not (yet) enough commercial interest in
>contributing to Wine development to provide the manpower, although that is
>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?
I responded, inter alia:
>This is all relevant, of course, only *if* significant expansion of the pool
>of developers is a desirable goal.
More information about the wine-devel