modular -> monolithic

[Alan Cox]

> - it's less likely to break anything else (read: in the xserver or libs)
> - it's easy to go back (just save the one driver file before)
> - build time is *much* less than with the monolithic tree.
>   This especially holds for drivers, which really compile fast.

rpm --install
rpm --erase

(and debian equivalents)

Replacing whole libraries is a big deal but flipping versions nowdays
isn't, whether its the X server package or X bits of package.

Compile time is down to Makefiles - if your Makefiles are right then any
small change build will be fast (and ccache helps too).

> Most of the time we're not actually talking about testing here, but
> about building. Often drivers or subsystems don't even *build* after an
> API breakage lately. Having *working* drivers is what we would actually
> like to have, but we have to tackle the build problem first. :-(

And having all the drivers in the build forces that to happen. In kernel
space the rule has always been "you break an API you co-ordinate and/or
sort the fixes". I'm not saying one way is right or wrong (its years
since I hacked on X so I don't claim to know what works for X).

> But please keep in mind that (apparently) working on the kernel is much
> more sexy than working on X, otherwise I wouldn't understand why so many
> people try out newer kernels, compared to the number of people trying
> the current X bits.

Now ask why ? I mean it shouldn't be the case. Video is hot stuff,
especially with the 3D bits being opened. Desktop I would point out was
also once "not sexy", until Gnome and KDE both somehow made them so.

> You could do that in the kernel as well, but apparently the mindset is
> different, and breaking internal APIs without fixing the code using this
> API is considered bad behavior (TM).
> 
> I think we're very much missing that mindset in X ATM :-(

Yes - and in the kernel it acts as both a restraining influence (its a
lot easier not to break an API so you need a good reason), and a
stabilizing one (its easier if you organically evolve the APIs rather
than breaking stuff).

Too many bits, not enough developers makes any development hard however
and there is an argument that simply throwing out unmaintained stuff is
the right way to transmit the pain to the people who use it and need to
support it 8)

Alan