Re: Modulesets Reorganization

[Mikkel Kamstrup Erlandsen <mikkel kamstrup gmail com>]

On 2 June 2010 01:37, 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.
> SNIP
> Comments, ideas, and suggestions are welcome.

Hi Lucas and Releases Team!

Wow lenghty thread, but most interesting read!

Generally I am all for a restructuring of the way we think about
modules and the initial proposal sounds mostly like what I'd suggest
myself.

I can however easily follow the worry of application developers for
loosing the Apps module, and to lesser (but still some) extend the
trouble for the distributors for selecting the right apps to
distribute. I think that an apps module still makes sense, but in a
revised form, because the current one has worried me deeply for a few
years now.

Here follows my proposal for a revised Applications module. Firstly
let's consider what and optimal solution would be:

 * Promoting the best, but also make good alternative noticeable
 * Consist only of high quality apps of all sorts
 * Be open to anything with sufficient quality
 * Easy participation for spare time contributors of all sorts
 * Easy participation for companies and professional contributors
 * Reliable delivery for vendors
 * Entice/reward developers to produce better apps

Here are the some of the features of the current approach that I
believe ultimately works against these goals (even though they may
have other merits):

 * Enforced hosting
 * Enforced VCS
 * "One appp per task" ie. not both Rhythmbox and Banshee
 * Apps that are too specialized do not have a place

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.

GNOME INCUBATOR
Getting into Gnome Incubator is not a freebie. Stuff in the incubator
is something that we expect will seriously contend for inclusion in
the portfolio some day. Being in the incubator should be enough of a
QA stamp that it attracts some mindshare - reviews, patches, i18n,
a11y, etc (the marketing team can help with showcasing and such). Its
a badge of honour.

Here are a few suggestions that could be points to assess when
deciding whether something should have the honour of going into
incubator:

 * Project age (many projects die early on after a few months)
 * Size of codebase (two .py files in a tarball is not enough)
 * Number of contributors
 * Code quality
 * Activity/project healthiness
 * How many similar projects are in incubation/portfolio

Note that incubator has *no* requirements for build system,
dependencies, i18n, a11y, autofoo, help docs, HIG compliance, hosting,
being generally useful (specialist apps are ok), or anything.  It does
imply that we expect that these qualities develop over time though,
helped also by the added attention the incubation will bring.

Unmaintained projects or projects with unfixable problems (fx.
political or social) can be removed from the incubator by the release
team. Generally I'd expect projects to be incubating from 6 months up
to a few years.

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

TRANSITION FROM GNOME 2
I'd propose that all apps in the Application Module (that want to) can
go directly into the Gnome Application Portfolio. At their discretion
of the maintainers they can go into incubator - which might actually
make sense if the project wants some motivation and review.

BONUS
We could consider applying the same methodology for Desktop,
(Extended) Platform, and Mobile. It's not as good a match as the apps
are in my eyes though.

I believe that this structure would address all of the bullet points
in the start of this very long email. Thanks for staying with me so
long!

Cheers,
Mikkel

[1]: http://apache.org/foundation/how-it-works.html#incubator