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