Suggestions for improvement of the emulator

[Francois Gouget]

On Tue, 6 Sep 2005, Troy Rollo wrote:
[...]
> Having to pipe all the changes through one person limits scalability.

This is far from being an issue with the current number of patches. By 
the time it becomes an issue I'm sure we'll have switched to a 
distributed repository model with different maintainers for each part of 
Wine. But you also have to realise that expecting to have multiple Wine 
maintainers right now is unrealistic due to lack of volunteers with 
enough time and who would be here for the long haul.

The only issue is when he takes a vacation but that's not very often.


[...]
> Even as things are now there is a disincentive to new developers. Some
> developers don't bother submitting patches because they feel it's too much
> work to get them accepted, and sometimes the patch doesn't get written at all
> because there is not enough certainty that it will be accepted.

Whatever the project or development model there is the risk that the 
patch will have to be reworked before it can be accepted. It's necessary 
to ensure the quality of the code and in order for the project to move 
forward rather than collapse repeatedly like a badly planned building.


[...]
> How many times have you seen people say that "Alexandre doesn't always know
> what he wants, but he knows what he doesn't want"?.

Hmmm, one? But it's unfair to expect him to solve everyone else's 
problems. One does not need commit access to suggest solutions to the 
current day's problem and when he is presented with a good solution 
Alexandre is quite able to say that he likes it. Otherwise you just have 
to accept that nobody knows what the right solution is. Then the only 
solution is to try one out to see if it is workable, then another one 
and so on until you find one that sticks. That's very much the 
development model of the Linux kernel btw.


[...]
> I suspect the current model is either at or near its limits. It would
> certainly not cope with a significant number of commercial outfits putting in
> a serious level of contribution, nor does it encourage them to make the
> attempt.

I can assure you that there are many more important factors that might 
dissuade a company from getting involved in Wine besides 'it's hard to 
get patches committed'. The saying 'Whatever you do, don't compete 
against Microsoft' would be one for instance.


[...]
> To scale better you would need to divide the project into different areas of
> responsibility and have multiple committers.

Well, we already have different committers for Wine, the website and the 
application database. But again it's the finding volunteers with the 
required knowledge, skill and free time that is going to be a problem.


> Almost every subdirectory of "dlls" could in principle be a separate 
> area of responsibility with a separate group of committers, although 
> it might be more convenient to have more-or-less related 
> subdirectories under the umbrella of a single group.

I mostly agree here. Actually I think we could easily have 2 or 3 
developpers per dll or group of dlls which means we could have many more 
developpers without having them step on each other's toes too much. Once 
we get to that level of development we'll see if Alexandre becomes the 
bottleneck but we are very far off.


> Each group responsible for an area would need to be prepared to give advice
> to people working on some patch in that area that if followed would make it
> virtually certain that the patch would be accepted.

Having more people give advice and help new contributors would certainly 
help. But the people giving advice don't need commit access to do that. 
Some developpers like Mike McCormack and Dmitry Timoshkov have been 
quite active in this area and I think they had a positive effect. All 
that's needed is subscribing to wine-devel and wine-patches, some Wine 
experience and the time plus the will to review patches.


> A supporting facility you would probably need would likely include either
> separate mailing lists for each sub-project (things get lost in wine-devel
> *now*) with consolidated read-only lists for people who want a convenient way
> of watching all of the discussions or a shift to an NNTP heirarchy with
> mailing gateways.

I don't think there is too much traffic on wine-devel yet. At this point 
I feel that splitting up wine-devel runs a much greater risk to dilute 
discussions and extinguish them because of lack of participants. The 
number of emails without an answer would certainly rise.


[...]
> Even with the Linux kernel, which is the only project that I am aware of that
> is comparable in size and follows a similar model to Wine, there appears to
> me to be some greater division of responsibility.

The Linux kernel is a much bigger project that Wine. I count almost 5 
million lines of C code versus less than 2 million for Wine. They also 
have many more contributors. Just as a comparison, the lkml gets twice 
as much email in a week as wine-devel in a month!


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

Yes, it definitely is. 
So the conclusion (mine anyway) is:
  * we need more volunteers to review patches and provide suggestions for
    improving them
  * we need more volunteers to help and maybe even informally 'mentor'
    new developpers
  * we need all Wine contributors to realise they should not wait for
    Alexandre to solve Wine's architectural problems or set directions
  * we could probably advertise more for Wine in universities and Linux
    user groups by making presentations/demos

-- 
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
       Any sufficiently advanced bug is indistinguishable from a feature.
                             -- from some indian guy