DIB clarification

James McKenzie jjmckenzie51 at earthlink.net
Sun Aug 29 19:00:05 CDT 2010

Juan Lang wrote:
> Hi Jeff,
> this has in fact come up before, and been addressed.  The main problem
> with the current attempt, as far as I know, is that the risk of
> regressions is so high that only very high quality changes stand any
> chance of getting accepted.  In the case of a DIB engine, the attempts
> have usually required accepting a large piece of new code wholesale,
> with a promise of future fixes.  This is a very risky way to make a
> change, and Alexandre has repeatedly shown his preference for small,
> incremental changes wherever possible.
Juan and others:

One additional note:  We should, as a project, not accept 'broken' 
code.  I work with a real-time project and get paid for this that soon 
will have this policy in effect.  No broken code, it is way to hard to 
go back and fix it later.  This is one thing I like AJ for.  The DIB 
engine is his one execption in that he wants it fully implemented and 
all in one piece.

Also, Max's code has shown up in another 'for pay' project and where 
implementation was done, works.  Where implementation is not complete, 
it is seriously broken.  The problem is where it works and does not work 
is not cleanly defined.   Lots of 'surprises' and 'gotchas'.

Anyway, Jeff, please look at Max's code and then ask AJ for specific 
guidance on the how to work on this.  This is a MAJOR part of the 
project that needs to be implemented.  Don't feel insulted when you get 
reject after reject from AJ.  As specific questions, and he does give 
answers.  If he states "it's broken"  he wants you to figure it out and 
the brokenness is very obvious.  Yes, I've had patches rejected by him 
and that is all he said.  I figured out the brokenness and fixed it.  
I've had to back off the patch as it used code that was rejected and now 
I know why.

James McKenzie

More information about the wine-devel mailing list