Suggestions for improvement of the emulator

[Troy Rollo]

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 should preface this by saying that I don't mean any criticism or offence by 
this.  You asked the question and the following reflects my observations of 
current limits to the development model and what would have to be changed to 
improve scalability. That doesn't mean the model has not served well thus far 
or with the available pool of developers to date.

Having to pipe all the changes through one person limits scalability. Until 
recently the facilities didn't even exist for supporting the maximum 
scalability using that model (distributed branching), and even though they 
exist now few people are using them and they are not integrated into the 
central commit process.

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. Before you 
suggest that this is speculative, I have one developer here who has made 
patches to fix Wine bugs experienced at home and not submitted them for that 
exact reason. You can try getting guidance on what is likely to be accepted, 
but again you run into a bandwidth problem with Alexandre - one person cannot 
effectively give guidance to everybody who needs it, and such guidance as he 
is able to give doesn't always help that much. The process requires that 
developers risk their work amounting to nothing because it won't be accepted. 
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"?. That perception is partly 
due to the fact that it is impossible for one person to take the time to 
really understand what is wanted for every area of Wine that is being worked 
on at any one time (humans are linear, it limits them).

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.

To scale better you would need to divide the project into different areas of 
responsibility and have multiple committers. You could have overall 
guidelines, but you'd need to be willing to trust the managers of each area 
to make final decisions in that area - even so far as to let them make 
mistakes and let them learn from those mistakes. 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. 
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.

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.

These structures are nothing new - most of the really big projects work this 
way - look at Gnome, KDE, and for the insane end of the scale, Debian.

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.

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