Suggestions for improvement of the emulator

[Robert Lunnon]

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