Re: Modulesets Reorganization

[Tomeu Vizoso <tomeu vizoso collabora co uk>]

On Wed, Jun 2, 2010 at 1:37 AM, Lucas Rocha <lucasr gnome org> wrote:
> Hi all,
>
> The release team would like to propose some important changes in the way we
> organize our modulesets. GNOME releases are currently organized into the
> following modulesets: Desktop, Platform, Bindings, Mobile, Admin, and Dev
> Tools. This model has served us well and has actually evolved through time - we
> didn't have the Admin and Dev Tools modulesets initially. However, we feel that
> this organization is reaching its limits, and we have explored several
> potential changes.
>
> Current issues
> --------------
>
> A set of issues makes it clear the need for an evolution here:
>
> 1. The arbitrary separation between Platform and Bindings can lead people to
> think that the bindings are second-class citizens while this is certainly not
> the case.

Moving bindings modules to the Desktop moduleset won't make them less
second-class citizens as long as API that is not bindable without
resorting to language-specific glue code keeps being added to
Platform.

Examples of this are GVariant (which affects GSettings) and GDBus, in
the latter this question was raised on gtk-devel but nobody showed
interest in how to make the new functionality available to bindings:

http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html

I don't think the authors of those APIs are to blame for this, because
they asked for feedback before merging and nobody cared about non-C
languages then.

It's nice that the release team worries about bindings because lots of
software is written for GNOME in languages other than C. But today we
are seeing a disproportion between the people who use bindings and
those that build them and it worries me a lot. What will happen to
those applications when old APIs such as GConf are not available any
more and GSettings is not available to their language?

An action more in accordance with the intention of making bindings a
first class citizen would be to require new API (with exceptions for
low level glib stuff) to be bindable by the introspecting bindings,
and also maybe some thinking into why the bindings landscape is in
such a mess right now.

Could be something like this be added to the criteria for platform libraries?

Presently, we have this stub for what is considered as "bindable":

http://live.gnome.org/GObjectIntrospection/WritingBindingableAPIs

Regards,

Tomeu

> 2. The Desktop moduleset has expanded so much that it's now unclear which type
> of application should go in and which shouldn't; it's also forcing us to choose
> one application over another, or to avoid any decision - like in the famous
> Rhythmbox vs Banshee case.
>
> 3. We strongly believe that we should encourage a strong ecosystem of apps
> around GNOME, and integrating all applications in the GNOME Desktop moduleset
> is not the best way to achieve this.
>
> 4. Some libraries should be used by developers even if the API/ABI guarantees
> are not as strong as our GNOME 2 Platform (e.g. GStreamer, e-d-s, and others).
> Such libraries should be labeled as such, obviously.
>
> Proposed (re)organization
> -------------------------
>
> With that said, the release team would like to propose the following
> reorganization of the modulesets:
>
> 1. The Desktop moduleset will only contain the components needed to get a
> desktop session running and provide core functionalities (e.g. gdm,
> gnome-session, gnome-settings-daemon, nautilus, etc). All applications
> providing extra relevant features to the desktop (e.g. gedit, Totem, Tomboy,
> etc) will be moved out from the Desktop moduleset. See the Extra Information
> section for more details.
>
> 2. Bindings will be merged into the Platform moduleset and become first-class
> citizens on the development Platform. The goal is to make the bindings more
> prominent from a communication perspective.
>
> 3. Create a moduleset to hold our highly recommended libraries such GStreamer,
> e-d-s, and others. This moduleset will be called Extended Platform.
>
> 4. Admin and Dev Tools will be dissolved and will be promoted like any other
> GNOME application. See the Extra Information section for more details.
>
> In summary, this means that the GNOME releases would be composed by the
> following modulesets:
>  - Desktop
>  - Platform
>  - Extended Platform
>  - Mobile
>
> Extra Information
> -----------------
>
> We're planning to do the actual reorganization of the modulesets as soon as
> possible during this development cycle. The idea is that GNOME 3 is released
> using the new modulesets.
>
> The long term plan for the GNOME applications that were removed from the
> Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality
> applications using the GNOME platform through our communication channels
> (release notes, website, etc). There will be no "official" apps anymore and no
> 'Applications' moduleset in the GNOME releases. The goal here is be more open
> with the app developer community around GNOME and to highlight all the nice
> things that can be created using our platform.
>
> Comments, ideas, and suggestions are welcome.
>
> Cheers!
>
> The Release Team
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>