next level of freedesktop.org

[Mike Hearn]

> 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 freedesktop.org hosting.

"On an indiscriminate basis" might be a bit vague. I'd second the motion
that it'd be restricted to projects either:

a) Useful for cross desktop project collaboration (desktop-file-utils,
pkg-config)
b) Shared infrastructure between various Linux desktop projects (Xr is
one obvious example)

I guess there's some overlap there. For random projects there is always
SF, Savannah and I suspect given the recent problems the 'forge has been
having, people will increasingly move back to hosting their own things,
I know I have.

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

There might be overlap with the LSB to a small extent there - they are
examining perhaps folding the GTK ABI into their specifications. OTOH
the LSB has far more stringent requirements than is typical of desktop
Linux, so the overlap would be small.

If it's generally restricted to shared infrastructure I think that'd
definately be a useful thing to have.

> Future areas of freedesktop.org work could also have an implementation
> component:
> 
>  - some shared library for the URI namespace (VFS/ioslave)
>  - a sound server

On the sound server thing - the advent of dmix in ALSA means that, at
least for Linux, those who don't need network transparent audio will no
longer require sound servers, as mixing/resampling is done in userspace
direct in the DSP buffer. Now, freedesktop.org arguably applies equally
to our friends using FreeBSD and Solaris, but it's worth bearing in mind
that in most other operating systems I've seen, sound server duties are
handled by a lower level than "the desktop".

> If for example projects such as XFCE or ROX wanted to use
> freedesktop.org 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.

Such things take considerable time to support. But, if people are
already volunteering to help out then perhaps that's not so bad :)

> 2. Hosting
> ===
> 
> Suggest the following:
> 
>  - a larger server (more mem/cpu/disk) to handle more traffic
>  - dedicated list server rather than using listman.redhat.com
>  - a bugzilla instance
>  - cvs infrastructure to allow maintainers to put ACLs on their cvs
>    modules

CVS or subversion? I know a few projects using subv, and at some point
am planning to move my own projects over to it. From what I've seen and
heard, it's pretty stable, and it already has many advantages over CVS.
On the other hand, you might decide that the higher
familiarity/penetration of cvs is more important.

> 3. Platform Release
> ===
> 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.

Where people == users or distributions? (or both)

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

That could prove politically interesting, esp once you start getting
groups pulling both ways - developers and bleeding edge users who want
updates twice a year, and corporate types who don't.

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

Yes.... I think that could work. The LSB certainly missed this target by
a light year or two, it's probably worth a shot here.

thanks -mike