Re: Moduleset Reorganization -- Take two

[Paolo Borelli <paolo borelli gmail com>]

Hi Vincent,

	I still have mixed feelings about the proposed moduleset
reorganization, though I think it is definitely better than the original
proposal. It seems to me that we are pretty much just ratifying our
inability to actually make choices... distros will just ship one music
player, one browser etc.


Anyway for now I'd like to concentrate on a separate point: I think
dismantling the development tools moduleset is an error. Having a clear
message on which are the preferred tools for development is crucial to
attract new developers and "what should I use?" is one of the more
frequent questions for new developers approaching gnome.
 

Ciao

	Paolo


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