Re: Modulesets Reorganization

[Milan Bouchet-Valat <nalimilan club fr>]

Le mercredi 02 juin 2010 à 22:08 +0200, Mikkel Kamstrup Erlandsen a
écrit :
<snip>
> My proposal is to let us inspire by the Apache Incubator idea[1],
> making app inclusion a two stage process. Mature in the Gnome
> Incubator and then when the project is mature and well maintained it
> gets the honour of graduating into the Gnome Application Portfolio.
> 
> It's important to note that we should be able to have several
> competing apps in both incubator and in the portfolio. It might not be
> a good idea to have 10 music players, but 3 or 4 should not be a
> problem. Distributors and contributors alike can make their own
> choices and pick their favourite(s). So I call it "portfolio" because
> it's not a "module" where we expect distributors to ship everything,
> but a collection of blessed top notch stuff.
But isn't GNOME's failure to decide on a blessed music player the reason
why we now have the choice between (at least) two good ones which are
mostly equivalent, instead of one excellent? The same applies to
Rhythmbox vs. Banshee and GThumb vs. F-Spot vs. Shotwell vs. Solang: I
suspect we may be wasting energy in largely duplicated efforts.

OTOH nobody has tried duplicating Evolution, Eye of GNOME or Evince - or
if they have, that's gone unnoticed, which amounts to the same. Once an
application is an official module, people know they better improve it
and join their efforts rather than starting their random project
elsewhere; eventually we get better software.

I think the idea of an incubator and an app portfolio is great for
"optional" apps, but for *essential* applications, making a (hard)
choice at some point is really important. See how Brasero has improved
and integrated nicely with all the desktop where GnomeBaker and others
had failed for many years.


> GNOME INCUBATOR
<snip>
> GNOME APPLICATION PORTFOLIO
> When an application has been in incubation and has reached maturity
> the maintainers, or the Gnome release team, can propose it for
> graduation into the portfolio, the highest honour we can attribute to
> a project.
> 
> In addition to the points evaluated for the incubator (leaving out the
> last one about similar projects) the following points should be
> considered when evaluating a project for joining the portfolio:
> 
>  * i18n, l10n
>  * a11y
>  * help docs
>  * Build system must be autotools
>  * Integration
>  * HIG compliance
>  * Using only blessed deps
>  * Project hosting (and VCS) is on a list of approved sites
I'll second people concerned about the consistence of the
infrastructure here. I guess "Approved sites" includes Launchpad,
which I appreciate in many regards - but the whole point of defining
official modules and branding their sum "GNOME" is to get them work together.
Not only translators would have a hard time using different VCS, but
developers will stay each on their module. There will eventually be a
core GNOME on git.gnome.org, and second-class modules all over the
place.

If people aren't happy with the infrastructure, then it needs to be
improved, not escaped. Anyway, for git, it's not an argument, since one
can always use a bzr bridge.


And one more message in this interesting-but-growing thread! ;-)

Regards