xc/programs considered harmful
Keith Packard
keithp at keithp.com
Fri Dec 17 16:15:52 PST 2004
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>
More information about the xorg
mailing list