Suggestions for improvement of the emulator

[Robert Lunnon]

Excuse the top posting, yes, this is exactly my point.

On Thursday 08 September 2005 11:02, Troy Rollo wrote:
> 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.