Firstly , we are talking about a governance model here, not an individual. Read on...
On Tuesday 06 September 2005 23:26, you wrote:
On Tue, 6 Sep 2005, Robert Lunnon wrote:
On Tuesday 06 September 2005 19:20, Francois Gouget wrote:
On Tue, 6 Sep 2005, Troy Rollo wrote: [...]
Having to pipe all the changes through one person limits scalability.
[...]
I must disagree, the LOTM (Lord Of The Manor) governance model may work for an small outfit but wine has already outgrown it. I have two or three withheld patches which are absolute show stoppers for running wine under Solaris. They are withheld despite the fact they work because they were refused,
So you're saying that Alexandre is wrong to refuse your patches, not that he is overloaded and drops patches so often that it limits Wine's growth.
Then adding more committers would not help. (unless you play one committer against the other to get your patches accepted)
The way forward is to dig up the patches that were rejected, post them to wine-devel with the reason that was given for their rejection (because you asked why they were rejected, right?), and ask for suggestions on how to make them more acceptable.
I don't think so... I have provided the best solutions from an outcome point of view consistent with my (un)willingness to undertake months of work, or increase my maintenance load for little benefit. This simply reflects that Alexandre's value system is different from mine. The result is a stalemate. and shows that the project simply can't demand this of developers, it can only encourage, that's what's wrong, the encouragement isn't there....
but... The issue isn't about Alexandre, it's about a governance model that revolves around the opinion of a single person and whether the difficulty of having a patch moved forward is inhibiting the take up of developers. The proponents of this thread say yes, the governance model inhibits progress. Lets keep it at this level. I use my Solaris "core functionality patches" only to substantiate the argument that there are outstanding patches that inhibit the takeup (progress) of wine in the market. Interestingly even codeweavers has such patches that Jeremy White terms "Proprietary Advantage". This'd be good for me if I was making a living off Wine like codeweavers are. In fact perhaps I'd go out of my way to produce patches that wouldn't be accepted.
yet every second week I am forced to work around some portability problem introduced by someone else - not exactly ISO9001 quality assurance.
I don't see a way around that. Only users of a given platform can detect compatibility or compilation problems with that platform. We cannot expect Alexandre, or every single committer in a multi-committer system, to test on every single platform out there before each commit. Even on Linux we sometimes get compilation problems with weird libxml libraries, opengl issues, old compilers, new compilers, etc.
I'll grant you that we could possibly setup a TinderBox type of system but I feel that would be very overkill right now and even TinderBox can only detect problems after patches get committed.
I think you miss my point, this sort of code gets into Wine every day. Wine is already very linux centric and possibly getting more so. There's even talk of integrating Wine with the linux kernel. To me this is because the patch acceptance is not objective enough. Wine should have stated criteria for patch acceptance EG:
Functionality, Portability, Precision - EG precise windows like behaviour Form. Implementation.
in my opinion in this order
Alexandre favours precision, and implementation over functionality and portability which makes it much harder for developers to get patches accepted because developers have to guess the right implementation and get the semantics exactly right before it'll go in. It's the wrong approach to encourage a group of volunteers in my opinion. Remember the project has no inherent right to demand a participant change a patch, it will only succeed in this endeavour if it can command the loyalty of the participants. Loyalty comes from the value the project places on the individual participant. Chicken and egg situation, you need to make it easy enough to get patches through, in order to make the participant loyal enough to act on your demands for changes.
I'll go this much further and propose what I'd like to see in a governance model.
Value all developers equally regardless of race sex capability or newbieness Developer rights based on contribution Opinions valued and considered even if they are dissenting Tolerance of mistakes - Value all contributions successful or not Consistent objective assessment of submissions according to an objective outcome focused set of criteria by the community (Peer assessment), feedback of assessment for all submissions. Governance board elected by the community/stakeholders. Customer focus.
can it be done, yes, I think so.
Bob
PS - A good look at an online solaris man page would find most the problems I come across - http://docs.sun.com