modular -> monolithic

[Zack Rusin]

On Sunday 20 January 2008 14:20:34 Bernardo Innocenti wrote:
> To summarize, it seems there's interest in merging the
> drivers back into the server tree.

So here's my simple proposal on how to do it. 

I've used git submodule to create a complete graphics stack superproject which 
basically takes all the modular parts and creates a monolithic tree out of 
them.

One can check it out with:
git clone git://people.freedesktop.org/~zack/seken
(you'll notice the directories are empty so do:)
git submodule init
git submodule update

This will automatically checkout for you relevant projects.

So we get a monolithic tree from modular sources. Testers and developers alike 
can easily checkout all relevant projects while others still have the option 
of working only in the modular sources.

Toplevel directory gets a simple script or even a Makefile that compiles all 
relevant sources and:
a) we can add -intel or -ati options that for example would build only sources 
relevant to the intel driver (drm, mesa, xserver and intel driver parts), or 
even slap something like kconfig in there,
b) only maintained modules get added to the superproject
c) developers making changes are required to assure superproject compiles 
(which shouldn't be hard due to the fact that 1) all modules are maintained, 
2) there's an easy way to build all of them)

> 1) build time and build complexity

I think that works of the bat. If not then adding to the toplevel 
script -xserver-drivers-only, -drivers-only, -drm-mesa-x-drivers options 
would solve it and assure that developers who change only relevant parts can 
change relevant parts. 
Plus at this point a tinderbox with the superproject actually makes sense.

> 2) packaging

Is unchanged from the modular perspective. The only thing that changes is that 
with superproject we can tag/branch all parts together. So distributors could 
do: "git checkout xorg7.4" and automatically get all the modules xorg7.4 came 
with, knowing they all compile and proceed to create package like he/she 
would do from any autoconf project.

> 3) spreading the development burden

I don't think this adds a lot of burden on anyone. 

Maybe on one person who would maintain the superproject. It would be either 
the release manager and if not then if there's interest in such a solution I 
could be doing that.

So yea, it certainly wouldn't solve our problems but I think it makes a lot of 
sense to have a super-project which at least tracks how do different branches 
of different projects match. ("do i use Mesa 7.0.2 or HEAD with Xserver 7.2 
and what version of the driver?" becomes "checkout xorg 7.2" and all 
subprojects get the correct version)

z