What to include in 4.4

[Erik Harrison]

At the risk of sounding extremely lame, I was wondering if anyone had
a thought or filed it away under "Hrm, have to think about that" then
forgot.

Or, more likely, thought "Hrm, it's that Erik guy talking again. If we
close our eyes, I bet he goes away".

On 6/19/05, Erik Harrison <erikharrison at gmail.com> 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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 
> I know this is a long winded message, 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.
> 
> What does everyone think?
> --
> "This brings me back to a time where I had no worries.
> All I needed to do was watch Perfect Strangers."
> -Erik
> 


-- 
"This brings me back to a time where I had no worries. 
All I needed to do was watch Perfect Strangers."
-Erik