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.