Projects in xfce repos, ehm...
Brian J. Tarricone
bjt23 at cornell.edu
Fri Nov 21 01:54:32 CET 2008
Jannis Pohlmann wrote:
> Am Fri, 21 Nov 2008 00:56:12 +0100
> schrieb Benedikt Meurer <benedikt.meurer at unix-ag.uni-siegen.de>:
>> 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. Of course, the "core" installer
>> should not include every panel plugin (esp. since not every plugin
>> compiles on every platform), but maybe a nice set of plugins to get
> I kind of don't like the current two-repositories approach either. It
> has something of keeping those out of the main repository who do
> "minor" stuff. One repository might also lower the barrier for goodies
> developers to contribute to the "core" (whatever that is now) since
> they would not have to reach out into a completely different repository
> for that.
True, though a minor point at best. But, on the other hand, I guess
perception can mean a lot...
> I just read about the GNOME release process and I kind of like it. It
> seems like their release team comes up with the schedule and every
> component in the repository has to meet certain rules to be part of the
> release. Then everyone just uploads their releases to the server and
> than they the release. It doesn't really matter what's core and what is
> not - distributions will pick up what they want anyway.
The problem with applying this to Xfce (how I see it, anyway; maybe we
just need to try it and see) is manpower. Even the core apps aren't
very well covered maintainer-wise. It's fine to set a date -- "all
packages that want to be a part of 4.8.0 need to be in the release
folder by 23:59 UTC on 3 Oct 2009" -- but is it really practical for us?
Look at how we "handled" the alpha. We delayed 6 weeks because we
didn't think the packages were in good enough shape. Beta1 had a delay
too, though much smaller. What happens when there's a critical bug in
xfce4-panel that hasn't been fixed yet, and the deadline passes? Do we
really drop the panel from a major release?
And if you say no (which is what I'd say), we'd make a special case, and
then we're right back to defining classes for packages again: "core"
becomes "stuff so important we'd make a special case to delay a
release," and "goodies" becomes "stuff nice to have, but if not, we
Then again, maybe this problem isn't limited to us. In GNOME land, up
until recently, gnome-session was effectively as unmaintained as
xfce4-session before I picked it up. Ditto for metacity (though it was
picked up a bit longer ago). And yet, they manage to still pull off
> Maybe we just have a problem defining "core" because of the installer,
> the xfce-all-in-one tarball and our current complicated release
> process. What if we just got rid of these three things? Or at least of
> the current way release Xfce and think of the tarball/installer as a
> much less important thing?
I'd get rid of the 'fat tarball' thing entirely. It's useful, but only
minimally. The installer is a bit of a point of contention, but as I
said in my other mail, maybe a core/apps/goodies split like Christian
suggested would work.
Anyhow, it people think putting everything into one big svn repo is the
way to go, I'd be ok with that. (Except for keeping a separate
'archive' repo for stuff that doesn't work / is unmaintained.)
More information about the Xfce4-dev