Re: Moduleset Reorganization -- Take two

[Bastien Nocera <hadess hadess net>]

On Thu, 2010-10-07 at 13:38 +0200, Vincent Untz wrote:
> Hi,
> 
> The release team updated the proposal to reorganize the modulesets. We
> discussed a first version back in June [1], and there are a few visible
> changes:
> 
>  - we added a system platform category in the platform, and we now also
>    talk about dbus services there.
> 
>  - we listened to the feedback where people didn't like the fact that
>    inclusion of applications had no barrier to entry at all. We do think
>    the Core Desktop vs Applications separation is good, and we also
>    believe it's important to simplify the process and to be more liberal
>    for "simple" applications (ie, applications that won't be in the Core
>    Desktop).
> 
>  - we also listened to translators, who have a need for a simple
>    workflow. There is no perfect solution for now, but we propose a way
>    forward.
> 
> This is obviously an important topic, so please take some time to read
> the proposal and send feedback.
> 
> I apologize for this being a bit late; purely my fault.
> 
> Cheers,
> 
> Vincent
> 
> [1] http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00001.html
> 
> 
> ==================================================
> GNOME Moduleset Reorganization: Platform, Bindings
> ==================================================
> 
> We identified various issues with our current Platform moduleset:
> 
>   + bindings are not part of it, and feel like second-class citizen.
>   + some libraries that are targetted at the platform are not API/ABI
>     stable yet. While we should still encourage their use instead of
>     their alternatives, we didn't have a clear message for this yet.
>   + many modules that are actually part of our platform just appear as
>     external dependencies.
>   + dbus services were not technically part of our platform, while they
>     do provide API/ABI to developers too.
> 
> System Platform
> ===============
> 
> The System Platform is the set of libraries or dbus services that are
> used in GNOME, but are modules belonging to lower parts of the stack. We
> encourage their use for GNOME applications.
> 
> This set might change over the years, and API/ABI stability is up to the
> respective developers. However, we will encourage them to guarantee
> stability.
> 
> Candidates for this set include: ConsoleKit, NetworkManager, Xorg,
> avahi, bluez, cairo, dbus, geoclue, gudev, libxml, pulseaudio, udisks,
> upower.

And fprintd (as used in the old gnome-about-me, the new accounts
dialogue, and with special gdm support).

I'd add geoclue there as well, when it sucks less.

<snip>
> Extended Platform
> =================
> 
<snip>
> Candidates for this set include GStreamer, enchant,
> evolution-data-server, libcanberra, libgda, libnotify, gupnp, poppler,
> telepathy-glib, tracker, webkitgtk. Candidate bindings include
> java-gnome.

totem-pl-parser (as used by Totem and Rhythmbox)

> =========================================================
> GNOME Moduleset Reorganization: Desktop, Admin, Dev Tools
> =========================================================

> The original idea to have Desktop, Admin and Dev Tools modulesets was to
> separate some applications based on the target user: end-user, system
> administrator, or developer. It worked okayish, but it turned out that
> most applications just ended up in Desktop, and it started getting
> harder and harder to put a limit on what kind of application can live in
> the Desktop. Moreover, when there are competing applications for a same
> use case, we could not choose one application without sending a message
> that the other applications were not as good, and this forced us to stay
> neutral (the classical banshee vs rhythmbox example).
> 
> We propose a solution where we keep a core desktop, which is the part of
> GNOME that everybody uses, and applications, containing the various
> applications that people use.
> 
> Note: related to this, it's worth considering a tag-based approach
> instead of single-category like we did. The categories defined in the
> xdg menu specification can be used for this, whenever we will have to
> present applications in a categorized way.
> 
> Core Desktop
> ============
> 
> The Core Desktop is the set of components that are needed to get a
> desktop session running and to have it provide core functionalities
> (display manager, session manager, desktop shell, file manager, settings
> manager, etc.).

I'm guessing this will include system settings type functionality (like
the volume control, or Bluetooth).

Will that also include things like eog, evince, totem?

> Applications
> ============

<snip>
>   + the application developers do not have to use GNOME resources.
>     Critical resources, like the vcs or the bug tracker, have to be easy
>     to find and documented to help contributors. Additionally, the use
>     of OpenID is encouraged to avoid the need of creating accounts.

Pain. What's most interesting in having an application in the GNOME
infrastructure is that you can do drive-by fixes. If I use an app, I
don't need special accounts, or look for bug trackers, etc. to file
bugs, upload fixes, etc.

I don't really understand why we would need to make that change now.

<snip>
> We want to bootstrap applications with the ones that were proposed for
> inclusion for 3.0: deja-dup, pdfmod, simple-scan. In addition to those,
> we want to invite applications that have been historically close to our
> project (banshee, f-spot, rhythmbox), as well as various popular
> applications.

Of the applications you mention here, all of them use GNOME
infrastructure, except deja-dup and simple-scan, which use Launchpad.

As long as the sysadmins and bugmasters are responsive, getting accounts
and bugzilla modules created should be straight forward.

> Moreover, we encourage maintainers of applications that are part of the
> Desktop today and that are not core applications to consider helping
> with the bootstrap efforts of this application set by moving their
> applications there.

Cheers