modular -> monolithic

[Matthias Hopf]

On Jan 21, 08 16:43:05 +0000, Alan Cox wrote:
> > - 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

I thought we were talking about source repositories here - not packaged
binaries...

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

Replacing the whole Xserver with its complete infrastructure is
considered a big deal. For me at least. Especially, if something doesn't
work, I don't know whether this is due to the driver (which I want to
test) or due to some other change introduced in the meantime.

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

The typical user doesn't understand that. We're typically happy if they
can do a git clone (or even pull). And for big projects like the Xserver
the configure scripts are big as well and take quite some time.

I agree that the Makefiles could have more intelligence. Then, again,
this is automake.

> And having all the drivers in the build forces that to happen. In kernel

Yes, and who forces the drivers to actually be built?

> 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).

So, and what do you do if some breakage has been applied to upstream?

Right. I forgot. You do not have an upstream.
But what happens if you pull some change that magically doesn't build
all drivers any longer? I guess you just get rid of it, and ignore it
until it does.
We don't have that luxury in our development model, with having one
dedicated upstream git repository.

Again, this boils down to having the right persons doing the selection
job, who we - apparently - just don't have.

> > 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,

I agree, it shouldn't. I guess this is mainly due to the pretty much
closed development model in former days :-(
And the codebase is huge, and partly very old (I think we still have
some K&R code lurking somewhere). Not sexy.

> > 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).

Again, I think this is the development model. A large community, and
people dedicated to merging and selecting good stuff, is a model that
works extremely well.

I think there are few people in the X community that would be easily
accepted as code selectors, like Linus is in the kernel space. And even
those who might be accepted probably like coding themselves much more
(or are required to by their company) than actually doing selection and
merging...

Matthias

-- 
Matthias Hopf <mhopf at suse.de>      __        __   __
Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de