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
