Projects in xfce repos, ehm...
jannis at xfce.org
Fri Nov 21 02:24:08 CET 2008
Am Thu, 20 Nov 2008 16:54:32 -0800
schrieb "Brian J. Tarricone" <bjt23 at cornell.edu>:
> 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 started.
> > 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...
Yeah, I think so. Also, another thing is that if others get the chance
to be part of the release (like having their directory and tarballs
inside a 4.8/ base directory or something) everyone might feel more
involved. When 4.6 comes out there will be mainly us core developers to
celebrate the release itself ... I think (because it's just our stuff
that's being released). Yes, all psychological stuff ...
> > 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
> won't delay."
It's true, there has to be some kind of consensus on what may delay or
block a release. Older versions of plugins and programs often work with
newer versions of the core (unless there is some API breakage) so might
not be that critical if e.g. xfce4-appfinder isn't part of the release
(as long as an older version still works). Alternatively one could
just pick up an older release with updated translations and announce it
the new major version, done.
Of course some things are more critical. It might be worth finding out
how others (like GNOME) handle such exceptions.
> 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 releases.
> > 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.
Yeah, the installer has always received a lot of positive feedback and
I think has convinced a lot of people to try/use Xfce. Adding more
installers to the current core and goodies installers sounds
> 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.)
Yeah, the really old stuff that doesn't work at all and that nobody
really cares about anymore can go wherever you like :p
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
More information about the Xfce4-dev