Suggestions for improvement of the emulator
fgouget at free.fr
Tue Sep 6 04:20:48 CDT 2005
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
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
* we need more volunteers to help and maybe even informally 'mentor'
* 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
More information about the wine-devel