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.