modular -> monolithic

[Alan Cox]

> I frankly don't care if the drivers are in or out of the tree. But 
> merging them into the tree won't fix the actual problem, which seems to 
> be too little testing before changes are pushed upstream.

With complex code that is hard to test you need an easy public upstream.
Three things we learned in the kernel are

- You need a way for users to install new releases including building
them which is fairly idiot proof and painless. Not because the users are
neccessarily idiots but because they are usually busy.
- You need to get changes to testers outside the core developers fast
- The more of these testers you can turn into people willing to twiddle
with the fix and turn into bug fixers the better.

To a great extent internal testing isn't so important. A fast
change->break->report cyce means you find out what broke fast enough that
you know what needs fixing and can fix it before it escapes the devel
candidate trees. If you think about this in terms of information flow,
feedback loops and system theory it should be obvious.

X historically (Linux historically at least maybe not JimG historically)
has had blocks in place to this such as the contributor agreements and
the difficulty in signing up to the old XFree86 project.

If the kernel developed with everyone running Red Hat/SuSE Enterprise
releases and almost nobody would do anything but report a bug and wait
for the next vendor release we'd be in deep doodoo.

I do agree that where the code lives isn't relevant. The Linux kernel
puts it almost all in one place which makes it easier to do ABI changes
and to scan for/fix shared bugs. Putting the code in one tree doesn't
stop it being modular, putting the code in multiple trees doesn't make it
modular either.

Alan