On Fri  5.Mar'10 at  8:44:07 +0100, Ingo Molnar wrote:
> 
> Yeah. I've seen a few other bad arguments as well:
> 
>    'exploding test matrix'
> 
> This is often the result of _another_ bad technical decision: 
> over-modularization.
> 
> Xorg, mesa/libdrm and the kernel DRM drivers pretty share this signature:

I agree 100% with this!

I test the kernel often (running 2.6.33-05070-g64ba992 ATM) because
it is _easy_ for me. Every morning I simply do a 'git pull' + compile + install 
and I am ready to test the bleeding edge kernel. 
And everytime I complained about something breaking it got fixed.

Really, testing the linux kernel is a hobby for me because it is easy.

Whereas everytime I wanted to do that with Xorg it was such a pain that
I want to keep away from that mess.
 
>  - it's developed by the same tightly knit developer base who often cross
>    between these packages. Features often need changes in each component.
> 
>  - a developer to be able to do real work has to have the latest sources
>    of all these components.
> 
>  - a user just uses whatever horizontal version cut the distro did and never
>    truly 'mixes' these components as a conscious decision.

True!

Why can't there be a 'Linus Torvalds' for Xorg accepting patches from various
maintainers and keeping the whole thing tied up? Why can't it mimic the
'make menuconfig' way of selecting what to compile to have the guarantee that 
the whole thing will simply work nicely together?

If this could be done for the kernel (which from my user POV seems much more
complicated), I guess it could be done with Xorg. And Linux would have
more Xorg testers and be better as a whole.


------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to