Re: Modulesets Reorganization

Le 02/06/10 01:37, Lucas Rocha a écrit :
In summary, this means that the GNOME releases would be composed by the
following modulesets:
  - Desktop
  - Platform
  - Extended Platform
  - Mobile

That seems a very good idea. There were indeed a need to get bindings on the platform, and extend the platform is a good module set for libraries that aims to be in the core platform but are not there yet (API/ABI stability reasons, etc).

With that organisation I think libtelepathy-glib could already be promoted into 'Extended Platform'. It will be directly used by Empathy and Gnome-Shell at least. I also think it's used by vinagre.

So this is a big +1 from me (for what I worth) :-)

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.

I understand the difficulties to maintain an Application moduleset, and the need to extend a bit the definition to more modules, but I don't think this is the right solution.

With that definition, Pidgin is as GNOME as Empathy then ?!?

That means that GNOME applications could live in any VCS, on any server/infrastructure, with any licence, etc ?!? That will be a mess.

Also the current (already legacy?) method to propose an application in the GNOME desktop was a good opportunity to get community feedback, get more developers involved in the projects, and fix lots of GNOMEy issues the app could have. Also that was an opportunity for the app to move to the GNOME infrastructure. I take my experience with Empathy for this, we moved it to GNOME infrastructure in preparation of proposing it into desktop, it was a pain because of SVN but we did it (with new system I would certainly not have moved it to GNOME's SVN and would have kept it in Collabora's git). Also the first time I proposed Empathy it was rejected with a good list of reasons, those got worked on and that gave goals for the next 6months. That resulted in a better app proposed the next cycle and got approved. If we remove that module proposal for the desktop, things could have been different.

And my last issue with the proposal: All applications could decide their own release schedule ?!? That would be a total nightmare for distributions I think. See how GTK not following GNOME schedule proved to be a recurrent issue... See for a concrete example that could happen: During the GNOME 3.1.x dev cycle, Empathy is following the same cycle and Ubuntu decide to ship Empathy 3.1.x for their dev cycle too. Then 2 days before the GNOME 3.2.0 release, Empathy decide - since they are not really bound to any GNOME schedule anymore - to add new features to their 3.1.x unstable branch and delay the 3.2.0 stable release for 2 extra months. What is supposed to do Ubuntu for their planned stable release?? They revert to Empathy 3.0, or they delay their distro release for 2 months?

So my opinion is we really still need an *official* 'Applications' moduleset, with strong requirements to get in. Though, we could make it more flexible, for example we could accept 2 applications doing the same job without deciding which one is best (rhythmbox + banshee, empathy + ekiga). After all deciding which app is best is really a distro decision and does not limit to GNOME (epiphany VS firefox). I think we should give to distro a set of applications that follows strong rules (licence, release schedule, freeze periods, infrastructure used, defined set of external dependencies, etc) then let them pick the app they like in that set.

Xavier Claessens.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]