xc/programs considered harmful

[Ely Levy]

On Fri, 17 Dec 2004, Keith Packard wrote:

>
> Around 16 o'clock on Dec 17, Owen Taylor wrote:
>
> > I don't think people even know what "modularization" means; yes,
> > it means that an X.org release would involve more than one tarball and
> > more than one CVS module, but that's not a level of detail that would
> > allow someone to formulate a position on the idea.
>
> I guess I assumed that most people understood what the goals of a modular
> release are by this point.  But, that's probably not true.  Here's what I
> want from it:
>
>  +	Split drivers from core X server
>
> 	1	Allows fast driver releases and slow core X server releases
>
> 	2	Provides parity for in-tree and out-of-tree driver development
>
> 	3	Provides a mechanism for testing binary compatibility across
> 		server and driver releases.  Makes accidental changes
> 		immediately visible
>
> 	4	Lets people build HEAD drivers without also replacing
> 		all of their X libraries, core X server, X applications
> 		and fonts
>
>  +	Split applications out
>
> 	1	Match exising Linux packaging policy which splits X into
> 		many small pieces
>
> 	2	Make stale applications obvious -- an application which
> 		hasn't seen an update for 10 years won't get a new version.
>
> 	3	Reduces build time for people just wanting an X server from HEAD
>
>  +	Split fonts out
>
> 	1	These never (well, hardly ever) change.  But we currently
> 		"release" them every six months forcing random package
> 		churn
>
>  +	Split libraries out
>
> 	1	Ensure ABI changes can be discovered far in advance of a
> 		release -- replacing a library alone will make such
> 		changes obvious to the original developer.  Current
> 		mechanism means that all of the dependent applications will
> 		likely get rebuilt and the ABI change never noticed.
>
> 	2	Provide for rapid and minimal security updates.  6.8.1
> 		contained a small patch for a small library (Xpm).  Doing
> 		a full X release for that was a huge effort.
>
>  +	Combine released packages together for a 'complete' X release
>
> 	1	Reduce release manager workload.  Right now, the release
> 		manager has to vette patches to individual source files.
> 		With a modular system, the release manager would instead
> 		vette whole package releases.
>
> 	2	Provide different 'profiles', for server, client, docs,
> 		driver authors and application developers.  This would let
> 		people get the new X server without being essentially forced to
> 		also get new X libraries.

Doesn't it also include removing packages which are not maintained by
xorg?
like expact xterm or whatever other program that only get synced?
You said that maintaining 2 trees waste developers time
isn't that exactly the case with programs like that?

Ely