Re: Discussing issues

Egbert Eich <[email protected]>
Newsgroups gmane.comp.xfree86.forum
Message-ID <[email protected]>
Keith Packard writes:

 > During the RandR integration for 4.3, I was unable to run the Radeon
 > GL driver from XFree86 on any of my video cards which led to video memory
 > issues that were only fixed when the Radeon driver was updated shortly
 > before the release and my cards started working again.

Would you have felt better if this code was constantly changing and
breaking at different places while it was still under development?

 > For projects like the Render extension and RandR, integration would be 
 > even more difficult.  OpenGL is mostly a 'bag on the side' of X; the hooks 
 > necessary to connect external rendering into the system aren't nearly as 
 > invasive as the changes needed to support new 2D rendering or screen 
 > resizing.  We'd end up with two separate X servers with different 
 > capabilities and a constant struggle for everyone to make things work.
 > 

This is not true for Render. Render lives for a large part in
a separate directory or in fb. The modifications for drivers
to enable render were minimal.
Unfortunately the integration of RandR went everything but perfect
despite the fact that is was done within the tree. This makes me
think that these things sould be done in experimental branches
or even separate trees until there is an implementation that is
prooven to be working. The linux kernel does this all the time:

Many projects are developed completely separately and even core
kernel components are developed outside the 'official' kernel 
until they are considered stable enough to be merged.

To my understanding this is done even in the development version
of the kernel to let problems caused by still unstable technology 
not interfere with the rest of development. 
For this reason DRI keeps developing new versions and new drivers 
in a separate branch of the tree.

I have frequently been bitten by errors that were introduced
by completely unrelated work which have obfuscated the problems
I was trying to fix in the code I was working on.

Doing all the work within one tree will let us stumble over
each others instabilities all the time and makes debugging the
more tedious. I think this is one lesson we can learn from the
linux kernel folks. Other projects I have looked at (like gcc) 
don't seem to handle things much differently.

I for my part keep my own CVS repository and try to commit 
'upstream' only when I think my code is sufficiently stable.

Egbert.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.