Moduleset Reorganization -- Take two

[Vincent Untz <vuntz gnome org>]

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.

API/ABI Stable Platfom
======================

The API/ABI Stable Platfom works in the exact same way as the GNOME 2.x
moduleset, but it can also include dbus services that guarantee
stability of their dbus interfaces.

However, to the libraries of the GNOME 2.x moduleset, we also add the
stable bindings for GNOME, to make them first-class citizen in our
message to developers.

Extended Platform
=================

The Extended Platform is a set of libraries or dbus services that do not
provide API/ABI stability yet, but that fill holes in our platform and
that should end in our platform once they reach stability. We encourage
developers to use them instead of alternative solutions.

Additionally, bindings that are still in development will also be in the
Extended Platform.

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


=========================================================
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.).

This Core Desktop will be a moduleset, in the same way we did the
Desktop moduleset for GNOME 2. It will have the same rules, including
the requirement to use GNOME resources.

Initially, for GNOME 3.0, it will be populated with the modules from the
GNOME 2.x Desktop moduleset. However, we would like to slowly migrate
some modules to the Applications moduleset.

Applications
============

The Applications moduleset is a special set, aimed at selecting
applications that are GNOMEy. All applications are welcome to be part of
this set, as long as they satisfy our quality requirements, and we want
to consider all these applications as part of the GNOME project. For
instance, we will talk about them in the release notes of new GNOME
releases.

It is not a usual moduleset since the rules to manage it will be
different. We understand that the community thinks the barrier that
exists today to enter the Desktop moduleset is actually useful: it helps
ensure that applications are good, and it also makes the developers
proud of having their project accepted. We propose the following rules:

  + an application may be proposed at any time for inclusion in our set
    of GNOME Applications. Such a proposal should be sent to
    desktop-devel-list, where the community will give feedback.

  + feedback will not be centered around the goal of the application,
    but about its technical merits:
    - use of GNOME technologies
    - integration with the Core Desktop
    - usability and respect of the HIG
    - existence of localization issues or not
    - status of documentation
    - accessibility support

  + after one month, the release team will extract the community
    consensus

  + we strongly encourage the application developers to follow the GNOME
    development cycle. If a different development cycle is used, it has
    to be documented to help contributors.

    There are a few reasons for this: first, this will make sure that
    our downstreams (who follow our development cycle), but also this
    will help our community to know when to work on those modules
    (instead of having to track many different cycles; this will be
    useful for documentation and translators). This should also help
    guarantee that the stable release will not be full of bugs.

  + 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.

  + if the application is not hosted on the GNOME infrastructure, we
    nonetheless encourage the application developers to work with the
    GNOME localization team for translations, and to get their
    applications listed on l10n.gnome.org. The GNOME teams are known for
    their high-quality, and this is extremly important for consistency
    between applications.

  + discussion of how to integrate those applications together is most
    welcome on core GNOME mailing lists, like desktop-devel-list. The
    developers should feel part of the GNOME project.

It's worth mentioning that we understand that a unique workflow is
important in general, and especially for translators. Using
l10n.gnome.org is nice, and it's probably worth investigating some way
to have l10n.gnome.org interact with transifex.org, as well as
registering the GNOME translation teams in transifex.org, to support
applications hosted outside of the GNOME infrastructure. This way,
translators would still be able to simply look at l10n.gnome.org.

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.

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.

-- 
Les gens heureux ne sont pas pressés.