What to include in 4.4

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok, ok, since you're being naggy... ^_^

Erik Harrison wrote:
> There are those, mostly not long time Xfce users, that claim that Xfce
> is getting bloated. We've been over that many times before on this
> list, and no need to go there again. But it is something I think we
> might be able to address with a simple release restructuring.

Bloated, meh.  They have an official invitation to bite me.

Anyway, I tend to see release structure and software 'bloat' as somewhat
orthogonal issues.  But let's see...

> My own personal suggestion was to have an official set of goodies, or
> extras package. We could make this extra package include out file
> managers, XFC, and some of the other possible bits and pieces in SVN.
> This official set of goodies could provide additional services, or
> require additional dependencies, but still be in Xfce SVN, have a
> release that syncs with the core, and be supported.

I think the idea was to move the xfce-goodies from Berlios over to Xfce
SVN, but it never really happened.  If that did happen, it would be a
lot easier to make aggregate packages.  And when you say "packages",
what do you mean?  Big source tarballs?  RPMS?  .debs?  All of these
take time and effort to generate.

> My rational is, that Xfce has a pretty clear interface it provides
> (window manager with CDEish panel) which defines Xfce. Also, Xfce
> tries hard to be very modular, and as the system grows, it will be
> harder to keep modular. By having an extremely minimal core with a
> supported package of extras we no longer have to be as concerned about
> retricting some packages excessively just to make them meet stringent
> dependency requirements that we try to keep to.

Yeah, if you'll recall, we've babbled on and on about this several times
without really getting anywhere concrete.

> So, by way of example, I was thinking something like:
> 
> Core:
> Xfdesktop
> Panel
> Xfwm
> Session manager
> libxfcegui4
> libxfce4util
> MCS
> libexo (possibly)
> 
> Extras:
> XFC
> Xffm
> Thunar
> xfprint
> xfcalendar
> xfmixer
> pyxfce
> Various panel plugins, xffm plugins, and the like

If Thunar turns out to be what I hope it will be, I'd rather have it in
the core, and then xfdesktop will be optional for people that don't want
to use a file manager, or don't want to use Thunar.  In that case,
xfdesktop would probably move to the extras list.  But, that's more up
to Benny.  He may want to make some post-1.0 releases (whether just
bugfix or actually feature releases) without waiting for the next core
release.

But I guess that depends on whether or not we think that a file manager
actually is a core part of a desktop environment.  With the level of
integration (with the desktop) that is planned for Thunar, I'd argue
that yes, a file manager is indeed a core part of a DE.

Otherwise, I pretty much agree with your list.  None of the others in
the extras list are required to have the basic level of functionality
that "defines" Xfce.  I don't use xfprint, because I don't have a
printer.  I don't use xfcalendar, because I'm terribly disorganised.  I
don't use xfce4-mixer, because I use a hardware volume control nob on my
speakers.  Etc., etc.

There are a few panel plugins distributed with xfce4-panel, and a bunch
of goodies.  Perhaps these distinctions should be reevaluated?  Perhaps
there are some panel-supplied plugins that really aren't essential, and
some goodies that are pretty close to essential.  I dunno.

> Third Party Apps, with their own release cycle:
> Mousepad, Xfmedia, (Terminal?)
> 
> Third party apps aren't held to any rules. Their just live out there,
> and are indexed by directory.xfce.org, and we won't chide users for
> talking on the user list about them. They can have dependencies
> aplenty, their own release cycle, whatever.

Yeah, good stuff.  I like not having rules.

> The extras can have more complicated dependency requirements, such as
> being written in C++ and requiring XFC, or providing capabilities we
> don't use in the core, such as language bindings for Python. You don't
> need Python bindings for any of the core components, so no need to
> provide them in the core. But it is extremely nice, low level, Xfce
> oriented tech, so we provide coordinated stable releases, and 90% of
> distros will include it with Xfce.

Mmm, agree.  The core should be written entirely in C, and dependencies
should be kept to a minimum.  Extras can go nuts.

> The nice thing about this organization is that packages can move
> amongst these categories easily, as we like. Third party apps with
> solid development, where the developer wishes, can be moved into the
> supported extras, Extras who loose developers to other obligations can
> be moved out of the release easily without delaying it, until such
> time as a new dev can be found to bring it up to speed. Extra packages
> which become increasingly critical, such as if XFC was being used by
> another core component, can be moved into the core.

Not a bad idea.  I figure the only area where extras will move in and
out are in panel plugins.  The Xfce release cycle is a bit long and
inflexible for just about any other kind of app.  Accordingly, if extras
need to make bugfix releases after a full core release, they can do so
on their own.

Actually, I think I'm starting to nod off, so this last paragraph may
not make sense.  Or it may make sense, but not really have anything to
do with what I really think.

> I know this is a long winded message...

Oh, please.  I'm so much more long-winded than you are ^_^.

> ... but I think breaking the
> packages up this way has real merit, when thought about. It also is
> actually pretty close to what we do now, with the goodies package
> getting all tarred up and installerfied when Xfce makes a release. By
> officializing it a bit, it makes it easier to do stable releases
> quickly, answers the "bloat" claim pretty handily, while still
> providing a very rich and featureful desktop for users who want it
> all.

I tend to think that adding more packages to the mix will make doing
releases harder.  The real thing to do to make releases easier is to
just sit down and write some scripts to do automated builds and
installs, and then automatically build release tarballs, rpms, etc. etc.
 Someone (Olivier, Benny?) may have already done something like this.

> What does everyone think?

I think I really need to take a nap.

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCugjN6XyW6VEeAnsRAjTBAJ0XULLwOCnAl3raoh/YaHDl09obRQCfeUQx
LwvRONvSPAJB/CELicUaeJc=
=4tq/
-----END PGP SIGNATURE-----