Re: Modulesets Reorganization

[Xavier Claessens <xclaesse gmail com>]

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.

Regards,
Xavier Claessens.