On Thu, 8 Sep 2005 04:42, Jeremy White wrote:
But the best way to persuade me (and others) of that is to highlight the patches. Show me patches you've submitted, along with arguments for them, and persuade me that he has been wrong to refuse them.
I said I wouldn't comment further, but I think several people have completely missed the point.
The issue is not that patches get rejected. It is that in many cases there are many reasonable ways to implement any given thing, but only a subset of those will be accepted. This is particularly the case with any significant new development, and "do it the way windows does it" is not always the right answer, particularly if what you are implementing is Winelib related since Alexandre actually prefers things not directly dependent on Windows be "right" within his interpretation of "right" rather than consistent with what would be done if Microsoft were implementing the thing. *Nobody* but the person approving commits is going to be able to give reliable guidance on which of several different approaches to take in order to produce work that will be committed, except in the most trivial case. Where that is limited to one person, there are inherent limits to scalability.
Scalability is not boolean. You do not reach a particular point where it breaks, rather things deteriorate gradually at first, then at an increasing rate as you approach breaking point. As things deteriorate, the value perceived by new developers decreases.
Isolated volunteers who have already committed to the project and are prepared to accept these limitations are unlikely to see the problem. Volunteers who are not prepared to accept the limitations are unlikely to be heard at all because they will drop Wine and move on to other projects. Codeweavers tends to fall more into the dedicated volunteer category because that is where it sources its developers. Neither Robert nor I are entirely volunteers though, so there are other factors operating on our decisions.
If I were solely a volunteer I would have ceased contributing to Wine since I have other projects I can be more productive on, and Robert has indicated his similar position. That would be my position even though I believe that aside from the Linux kernel, Wine is the single most strategically important open source software development project in existence.
It should not make us happy that other projects are as bad or worse at scaling if there is the possibility of improvement. However if other projects of similar size (or greater) are better, then that is likely demonstrative of the possibility of improvement.
Is progress good? Yes. Could it be better? That is the question. Would this require a sacrifice to quality? Only if you believe Alexandre is infallible and that nobody else could competently shoulder any of his load - which raises the question of what happens if he encounters the proverbial bus. But nobody is infallible - not you, not I, not Alexandre. And I believe there are a number of people around here who could competently shoulder some of the load. That does not mean they have to make the *same* decision as Alexandre, just that they need to be making decisions that are within a legitimate range an acceptable proportion of the time.
Allow me to remind people of the original trigger for this discussion.
On Mon, 5 Sep 2005 06:24, Alex Tanner wrote:
If all the companies worked together on a single WinXP-Pro-emulating flavour of Wine, the manpower problem would be solved.
I responded:
Not really. Firstly there is not (yet) enough commercial interest in contributing to Wine development to provide the manpower, although that is changing.
Secondly, even if there were sufficient manpower, the way the Wine project is currently structured would prevent the manpower from being used efficiently.
On Mon, 5 Sep 2005 20:30, Francois Gouget wrote:
What makes you say that? What would need changing to efficiently accomodate *more* developpers?
(emphasis mine)
I responded, inter alia:
This is all relevant, of course, only *if* significant expansion of the pool of developers is a desirable goal.