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. -- devel-announce-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/devel-announce-list
