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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list