Suggestions for improvement of the emulator
bobl at optushome.com.au
Wed Sep 7 12:43:24 CDT 2005
Firstly , we are talking about a governance model here, not an individual.
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
> 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....
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:
Precision - EG precise windows like behaviour
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
I'll go this much further and propose what I'd like to see in a governance
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.
can it be done, yes, I think so.
PS - A good look at an online solaris man page would find most the problems I
come across - http://docs.sun.com
More information about the wine-devel