next level of

Havoc Pennington hp at
Thu Jul 17 05:36:17 EEST 2003


I'd like to see what people think about making some changes to to create a stronger "center of gravity" for
X/Linux/UNIX desktop development shared between the desktop projects,
toolkits, and applications such as Mozilla and

Concretely, I'm proposing the following steps:

1. We welcome desktop-related development projects on an
   indiscriminate basis; if it's desktop-related and open source, you
   can use hosting.

2. We move to better hosting facilities.

3. We investigate the idea of making a versioned "desktop platform
   release" that would be a distribution with multiple modules, much
   like a GNOME or KDE release. It would contain a snapshot of stable
   tarballs for various desktop platform components.

More details on each of these follow.

1. More Projects

Given better hosting and the option to use ACLs, there's no reason not
to be a wide open community where anyone who wants to do
desktop-related work is welcome. I've already been handing out accounts more or less to anyone who asks, but asking
isn't all that attractive, since we lack important things such as

One immediate need in this area is to host Keith Packard's work,
including the set of font libraries (fontconfig, Xft), and other
X-related work he would like to do.

Another obvious thing to host is Carl Worth's Xr library, as GTK+ and
I believe other toolkits are looking to use this as a vector graphics
engine. Xr has a couple of dependency libraries as well. already hosts D-BUS, CSL, pkg-config, and
desktop-file-utils, among other pieces of software, in addition to

Future areas of work could also have an implementation

 - some shared library for the URI namespace (VFS/ioslave)
 - a sound server
 - my proposed hardware library (
 - a configuration system?
 - useful bits factored out of or Mozilla

Undoubtedly people can think of more.

A question is whether we're interested in hosting any of the
applications themselves, or only shared underpinnings of

If for example projects such as XFCE or ROX wanted to use CVS, I think that would be fine. But perhaps there's
some line where we don't want to be quite as busy as sourceforge.

2. Hosting

Suggest the following:

 - a larger server (more mem/cpu/disk) to handle more traffic
 - dedicated list server rather than using
 - a bugzilla instance
 - cvs infrastructure to allow maintainers to put ACLs on their cvs
 - ssh rather than pserver for cvs access
 - some way to track real names and email addresses for each 
   cvs account
 - a server where people other than me can have shell accounts and
   help with server maintenance

Right now the cvs/web server is a fairly underpowered machine at Red
Hat and is not dedicated exclusively to, which means
I'm the only one who can log into it.

If we can host Keith Packard's work, we have an offer for a server on
a large Internet connection at Portland State University. This is
currently hosting

We can also host a server at Red Hat's colocation site, along with, but we would need to
find a server to colocate there.

3. Platform Release

Counting only what has so far, plus fontconfig, Xft,
Xr + dependencies, there are already quite a few tarballs to download
that are prerequisites to use GNOME, KDE, and the large apps.

You can easily get bad combinations of these tarballs;
fontconfig/freetype combinations that are no good, for example.  Plus,
it's annoying for people to track the version numbers and releases of
all these sub-modules.

My proposal is that we do a versioned release that defines the
expected shared underpinnings of the desktops, toolkits, and major
applications. This will let us depend on simply "desktop platform
release 3.0" for example, rather than specifying a lot of individual
components. It will also mean we test things as a whole, and users can
install them in one go. Finally, it gives us a central place to define
what platform the major desktop projects are expecting users to

The goal of a coordinated release will obviously be more useful as we
have more shared underpinnings in the platform. But I think it's worth
starting to work toward.


So that's it. I believe these changes would make more
useful, and remove some of the ways that it bottlenecks on me.
Comments are welcome.  Please feel free to post "me too" or send me
private mail, as otherwise it's hard to judge consensus.


More information about the xdg mailing list