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