Projects in xfce repos, ehm...

Jannis Pohlmann jannis at
Fri Nov 21 02:34:00 CET 2008

Am Thu, 20 Nov 2008 16:42:39 -0800
schrieb "Brian J. Tarricone" <bjt23 at>:

> Benedikt Meurer wrote:
> > This kind of stupid discussion repeats approx. once per year, and
> > its always the same arguments pro and con. Given that Xfce still
> > attempts to deliver a desktop environment and not only a window
> > manager with nice buttons to start applications, it's really
> > nonsense to talk about defining "core" w/o applications like the
> > file manager, editor, terminal, image viewer, etc. A default
> > install of Xfce should give you anything you need to get started
> > and this "default install" should be represented in a common
> > repository (and bug tracker, etc.) so that people who want to get
> > involved (few enough already) don't get frustrated having to look
> > up the source for these essential components first (no matter if
> > they want to contribute code, documentation, translations, or
> > whatever). If someone wants to replace application A with
> > application B, he/she can do this later, but this is a special
> > case; the majority of people (including myself, not just newbs as
> > someone will surely attempt to argue) just want a working desktop
> > environment, with file manager, editor and terminal at least!
> Yes, but: there are about 6 of us that work on Xfce decently often. 
> Getting all apps together for a release is harder when "all apps" is
> a larger number when you don't simultaneously increase the number of 
> people involved (which has diminishing returns anyway).

It's true that it'd be nice to have a better coverage of the important
components. That could make things a lot easier (heck, maybe I could
even study a bit apart from working on Xfce ;)).

The responsibility to have components in the release other than the ones
we can handle should not be put on us but rather on the people working
on it. For the most important ones we can try to share the release
responsibility among us. For the rest (like what currently is
called "goodies") each maintained would have to be responsible. 

> I'm not really concerned with the final end-user experience when I'm 
> talking about this distinction.  Packagers will set up their package 
> managers to install whatever subset of "xfce" packages they want when 
> the user says "install xfce."  I can't believe that most people would 
> compile from source from our tarballs, and those are the kinds of
> people who are perfectly capable of grabbing some packages from 
>$VERSION/, and others from the release
> directories on (or wherever else).  In fact, these
> kinds of people are, by definition, not included in your group of
> people you're saying we should care about.
> When I talk about this, all I really care about is maintenance burden 
> for us.  Changing these things don't really result in any more of a 
> burden on the user.  The only other people that should be affected
> are packagers, and we can do things to alleviate that, like making it
> easier to find all the various xfce-related pieces of software with
> something better than the current (like Jannis was
> talking about in a separate mail).
> > I'd even suggest to drop the separate goodies repository completely
> > and move everything into one repo similar to GNOME. That way every
> > Xfce maintainer is first-class.
> I was thinking about this earlier while composing one of my previous 
> mails.  I'm not opposed to it on principle, but I'm not sure that I'm 
> really in favor of it either.

The more I think of it, the more it sounds like an interesting option
to me, both on the psychological and the technical and release
engineering side. But it only makes sense if we re-think the
whole release process which is, I think, something we had planned
anyway. Along with an intelligent release strategy this might actually

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <>

More information about the Xfce4-dev mailing list