[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xfree86-forum
Subject:    Re: [forum] XFree86 modularization
From:       Egbert Eich <eich () XFree86 ! Org>
Date:       2003-06-02 14:27:14
[Download RAW message or body]

Hi Owen,

sorry for joining this discussion so late. I've been on vacation.

Owen Taylor writes:
 > 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.

Yes. In principle we could turn each app into a separate module.
The build process would allow that. Also it would not be a problem
to define these modules in CVS so that they can be checked out
separately while still remaining in the directory structure.

With proper tagging one could then check out the full tree with
the latest releases of each module or each module separately.

Modularization however will be more difficult for the servers. It would be
useful to place different servers (Xnest, Xvfb, XFree86, XPrint ...)
into separate modules however they share a lot of common code
(ie the complete dix).

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

We may even want to further subdevide the fonts.

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

On systems that usually come with the installed version
of these libs this installed version should probably be used as 
default.

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

This should all be there already.

 > 
 >  * 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'.
 > 

Are you suggesting to split the tree into separate repositories?
I don't think there is anything which we cannot do with proper
tags/modules in one single CVS repository.

Egbert.

[prev in list] [next in list] [prev in thread] [next in thread]