Re: XFree86 modularization

Hi Egbert,

Here's a quick (if late) writeup of my thoughts on X modularization;
I'm not sure it really addresses your questions, since the 
driver interfaces are the part of X that I'm least familiar
with, but perhaps it is useful anyways.

 * The easy low hanging fruit for modularization is the apps
   distributed with X. Separate distribution of xauth or
   mkfontdir probably doesn't make sense, but I could imagine:

    xterm - separate
    xedit - separate
    xclock, xeyes, texteroids, ... - demos package
    twm,xsm,xclipboard,xdm,xman,xmh ... - classic X desktop package 

   How splitty you want to get really depends on how many 
   pieces you have people interested in maintaining separately.

 * Fonts are another piece that strikes me as logically separate
   and trivial to split out. There's no reason that an upgrade of your
   installed fonts should be tied to an upgrade of your X server.

 * One thing I personally would to like to see split apart, or in
   fact, killed from XFree86 is copies of libraries that are
   independently maintained ... FreeType, zlib, expat, and now
   fontconfig. People whine about external dependencies, but in
   the end sucked in copies of the libraries do more harm both
   maintenance headaches and in multiple conflicting installs.
 
   I feel like I've spent years of my life helping people 
   with multiple different copies of FreeType figure out their 
   Pango compilation problems.

 * Drivers seem to be something many people are interested 
   having distributed separately, and it works well because
   there is more or less well defined API/ABI between them
   and the rest of the server. Having a clear DDK and versioning
   the API/ABI for the DDK is an important step.

 * The remainder, roughly:

    Protocol headers
    Server
    Server config files
    Library
    Library config files
    Docs

   Is harder to split apart; Keeping it as one chunk wouldn't
   be fatal, but if you were trying to split it, I think the 
   right split is probably

    Protocol headers / protocol docs
    Server / server config files / server docs
    Libaries / library config files / library docs

   Having the protocol headers a separate chunk might enforce a healthy
   degree of care when touching them...

   Xtrans is clearly a difficult issue for such a split. 

General observations:

 * There is a big win in being able to split out anything that
   you can identify a competent maintainer for, even if users don't 
   care about upgrading it separately. By splitting it out you're
   allowing the maintainer to proceed at their own pace and to get 
   their code and bug fixes out quickly if they think it is worthwhile.

 * By increasing modularization, you make things easier for the
   maintainers, casual contributors, distribution packagers, and
   people using packages at the expense of the person compiling
   from source just to say they compiled from source. So you have
   to be somewhat willing to turn a deaf ear to the complaints of
   the last. (Build scripts can help, too.)

 * Release management becomes more of a coordination effort 
   (do we have tarballs from everybody?) rather than one central
   'cvs tag' 'cvs export'.

Regards,
                                             Owen