xc/programs considered harmful

[Adam Jackson]

On Friday 17 December 2004 14:57, Torrey Lyons wrote:
> Unfortunately this topic turned into a debate about the modular vs.
> monolithic tree. I don't have a problem with the modular tree, but I
> and others do have issues with killing the monolithic tree piece meal
> to aid acceptance of the modular tree.

I'd like to point out here that hoisting chunks out of the monolith has the 
side effect of making the _monolith_ more maintainable.

I've given links to proposed package breakdowns.  I've explained how the 
server component would be broken down.  If there's really a desire for a 
formal enumeration, please let me know, I'll be more than happy to write one 
up.

You know what, why am I even asking.  Clearly there's a need.  Give me a few 
hours and some more Red Bull and I'll pound one out.

> If I had good answers to these questions, I would feel comfortable
> moving my day to day to development to the modular tree. However, I
> imagine many others are in my situation. We can sink some time into
> trying to figure all this out for ourselves about the modular tree,
> or we can just get the coding done that we care about in the tree we
> know works.

The only way to find out if the modular tree builds and runs on your platform 
of choice, is to attempt to build it and run it.  This does involve a certain 
level of buy-in on the part of the platform maintainers.  It's not fair to 
put the cart before the horse here, and expect a working build system to drop 
into your lap.

Step 1: Decide on a module layout.
Step 2: Write autotool magic for each module.
Step 3: Test the magic on all platforms.
Step 4: Apply platform fixes to autotool magic, iterate until working.

The code, the actual C source, is an opaque object in this discussion.  You 
can literally copy working code across from the monolith until you're 
confident in the build system.  Furthermore you can deploy these objects 
piecemeal in the modular tree; this is a _good_ thing, if you really had to 
do build and run tests on all 400 pieces of the monolith all at once you'd 
never finish.  Particularly if pieces keep getting _added_ to the monolith.

In other words, carving up the monolith until there's nothing left is the 
method that ensures the smoothest transition.  At some point we need to say 
that the next release, whatever its number, is the modular one.  Keep working 
on the _code_ wherever it lives.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20041217/112fc2f4/attachment.pgp>