Projects in xfce repos, ehm...

Jannis Pohlmann jannis at xfce.org
Fri Nov 21 00:46:55 CET 2008


Am Thu, 20 Nov 2008 15:25:27 -0800
schrieb "Brian J. Tarricone" <bjt23 at cornell.edu>:

> Jannis Pohlmann wrote:
> 
> > I think the problem is: How do we define the Core? Does Core just
> > mean it's managed in the main SVN, does it mean that it is shipped
> > with the main Xfce tarball on major Xfce releases or even something
> > different?
> > 
> > Right now, Core could roughly described this way: a component that
> > is considered essential for desktop use, is stable, and is not
> > released independently of the main Xfce releases.
> 
> That's an interesting point, and I've personally always had some
> amount of trouble defining "core" as well.
> 
> Maybe think about it in a different way: "what modules, if missing, 
> would make your desktop significantly 'less xfce'?"  And I'd say
> really just a few:
> 
> gtk-xfce-engine-2
> xfce4-session
> xfwm4
> xfce4-panel
> xfdesktop
> xfce4-settings (debatable, but I'd say yes)
> Thunar (?)
> 
> Then you add the support libraries and packages:
> 
> xfce4-dev-tools
> libxfce4util
> libxfcegui4
> xfconf
> libxfce4menu
> libexo (?)
> xfce-utils
> xfce4-icon-theme (?)
> 
> Thunar is a bit of a point of contention.  As a standalone file
> manager, I'd be tempted to say that no, it need not be a core part of
> the desktop.  But xfdesktop depends on thunar-vfs for file icon
> support, so I'd say make it core.
> 
> So that's only really 14/15 modules (out of 37 total.  Of course,
> this is all debatable.

Agreed. If you define "core" this way it makes sense. Discussing
different understandings of "core" is something I was hoping to start.
Even though I gave one possible way of understanding it myself I'm not
insisting on it. I can clearly see the maintainance benefit of keeping
the number of core components low.

I actually like both, the "essential to the user experience" and
the "essential for the Xfce 'feeling'" approach. But I can also see
Nick's point: if we see other components as "less Xfce" some of the
reasoning behind those applications might get lost and everything but
the core might just be seen as a random collection of applications
rather than one that is intentionally coherent and written with the
same goals in mind. I think they too build on the "Xfce spirit". To
maintain that we might have to promote the goodies in a more attractive
way maybe. 

> Should we keep the language bindings (perl, python, c++) in main or
> move to a new xfce-bindings repo?  I dunno.  Maybe just leave them,
> since they're kinda "foundational" even though we wouldn't release
> them as core.

Dunno. Are any of the bindings actually mature enough to act as more
than an experimental in-development feature? I wouldn't really mind to
move them somewhere else.

> I'd also leave some of the more "foundation/infrastructure" modules 
> there, like installit, xfce-installers, and xfce4-debs.

The installer-installit, yeah. Feel free to dump my unmaintained
"successor" of it somewhere else ;)

> So that really leaves the stuff that are applications:
> 
> mousepad
> squeeze
> terminal
> xarchiver
> xfcalendar/orage
> xfce4-appfinder
> xfce4-mixer
> xfce4-terminal (I need to move this to xfce-archive)
> xfce4-trigger-launcher
> xfprint
> xfce4-themes (add-on package, I guess, not app)
> 
> I'd say none of these are core apps.
> 
> (Since I know people will complain: Terminal.  It's a nice light 
> terminal, but it's not really xfce-branded.  You might consider it an 
> "essential desktop app," but that's not really the point I'm trying
> to make here.  It's not *a part of the desktop*, and it's something
> you can easily replace with aterm, gnome-terminal, or whatever, and
> your desktop -- in my mind, at least -- isn't any "less xfce" for
> doing so.)

Based on the understanding of "core" that you suggest I can agree with
all of this.

> > Now, several of us have expressed an interest in having independent
> > releases for minor releases at least, so that we can roll out
> > updates to one component faster and don't have to do complex release
> > management. If we did that and only pick up the latest release of
> > each package for a new major Xfce release the definition of Core
> > becomes: a component that is considered essential for desktop use,
> > is stable, and is released every now and then so that we can pick
> > it up for a major release.
> 
> My proposal (for the stable branch) would be to make all "x.y.z" 
> releases as official all-component releases, and allow module 
> maintainers to release "x.y.x.n" releases in between for important 
> bugfixes or well, even non-important bugfixes.
> 
> For the development branch, I'd go even more liberal and let module 
> maintainers package up devel releases whenever they want, with the
> only caveat that no one's allowed to use '90' or above for the
> revision component in the version, since we use those for
> alpha/beta/rc.

I think I'd be fine with that much liberty, but we may want to give it
a bit more structure I think ;)

> > So once the release process becomes easier the only thing that
> > really matters is how essential an application is for desktop use.
> > "Essential" again is defined by our understanding of the desktop
> > environment. IMHO we should concentrate on what the user needs and
> > to which degree we can fullfil that need using the components and
> > resources we have.
> > 
> > Personally I wouldn't mind to include more programs into the Core
> > like for power management and notifications for example, because
> > those make the desktop complete (IMHO Terminal, mousepad and orage
> > are essential even though I don't use mousepad). 
> > But I think what really matters is that more Core stuff does not
> > make releasing more complex. I feel that this should be one of the
> > things to focus on in the upcoming months. 
> > 
> > Personal opinion: Consider more applications as part of the Core
> > (but choose carefully) and don't make a big deal out of whether an
> > application is Core or not.
> 
> I'd go the exact opposite way: trim down the core as much as
> possible, and push everything else out, with completely independent
> release cycles and everything for non-core stuff.
> 
> I don't really like the scope creep in saying "essential to a desktop 
> environment" should be what core is.  We have < 10 people that work
> on Xfce actively.  "Xfce" should consist of as few packages as
> possible that make up the desktop *environment*, not the desktop as a
> whole. Distribution packagers can make the call to include whatever
> they want in their xfce meta-pacakge.
>
> On the other hand, I *would* consider something like a power manager
> a core app, since it does define policy for how the desktop env
> behaves as a whole.  The notification daemon... maybe.  It's
> certainly more a "desktop app" than mousepad, for example.
> 
>  > I also think there's room for improvements concerning the goodies
>  > releases. Important goodies should get more attention and should
>  > maybe get their own niché somewhere between core and goodies. Hmmm.
> 
> That's kinda a separate issue.  I'd rather not create yet another 
> release/hosting/whatever infrastructure.  Personally I don't think of 
> "goodies" as a tightly-coupled entity in its own right, more just 
> "random hosting for random apps that are somewhat related to xfce."
> And I think that's fine.

See my explanations above and the other mail I wrote in reply to
Christian on that topic. 

  - Jannis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20081121/71792f09/attachment.pgp>


More information about the Xfce4-dev mailing list