Moduleset reorg, new draft

[Vincent Untz <vuntz gnome org>]

Hi all,

Here's a draft of a new proposal for the moduleset reorganization. It's
similar to what we had before, with three main changes:

 - the platform also talks about dbus services

 - I introduced the idea of a system platform: this is partly based on
   what we have as external deps today, but it acknowledges the fact
   that it's in our platform (with limits, though: some modules there
   don't have any API/ABI guarantee)

 - the applications moved back from a "we include everything proposed"
   model to a "propose on ddl, extract consensus" model, except that
   this is still more liberal than the current modulesets (no hard
   requirement to follow the development cycle nor to use the gnome.org
   resources; can be accepted at any time during a cycle)

We can discuss all this at the meeting :-)

Cheers,

Vincent

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

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

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.

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.

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.