xc/programs considered harmful

[Keith Packard]

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.

> And how could there be a commitment to modularization for a particular
> release without an idea of what work is involved? 

It's a chicken-and-egg problem to be sure, but I think the existing 
demonstrations of modularized X environments provide sufficient 
information about the work needed to do the whole job.

> I think a specific plan, even if got completely reworked afterwords,
> would go a long way towards building that consensus.

I disagree. I believe consensus must be constructed first, at least among
the project leaders, so that those with less interest are encouraged to
help build the specific plan so that the plan will actually help and not
hinder them in their own work.

Plans have been proposed in the past but because there wasn't a community 
effort to build them, they fell far short of a complete solution.

It's not like we're adding a new capability to the system where a
demonstration serves to unite people behind the new functionality, this
particular problem has a large solution space and the "best" one depends 
tremendously on who you ask.

-keith


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