Re: Modulesets Reorganization

[Michael Terry <mike mterry name>]

On 1 June 2010 19:37, Lucas Rocha <lucasr gnome org> wrote:
> 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.

As the maintainer of Déjà Dup, I approve of this move.  I feel Déjà
Dup is a bit of a poster child for this change.

1) Déjà Dup already follows the GNOME schedule, watches GnomeGoals,
follows HIG, and uses GNOME technology.

2) Déjà Dup is already shipped in multiple distros.  Inclusion in
GNOME would just offer more marketing/developers (of which I'm
primarily interested in the latter), not necessarily Déjà Dup's
'chance to hit it big'.

3) Déjà Dup already has an infrastructure that works for me.  I'd be
very sad to move away from Launchpad, but was willing to do if it
meant access to the extra exposure.  But am glad to hear that I won't
need to.  I don't think using, say, GNOME Bugzilla would improve my
chances of attracting developers.

4) Not being under the watchful eye of release managers means I can be
slightly more adventurous (don't need to have dependencies approved).


One thing I had hoped to gain access to via GNOME is the documentation
teams and translation teams.  Launchpad provides very good translation
support, so I'm not hurting there, but my understanding is that the
GNOME translation teams are more comprehensive/committed.

It would be nice if the new Applications scheme had some facility for
improving cooperation between those teams and externally-hosted
applications.

Maybe for willing applications in Launchpad, that means:

1) Having an approved GNOME coding team (~gnome-team?) that the
maintainer sets to own the branch.  This way, documenters and
GNOME-approved coders can directly commit.

2) Having the maintainer set the approved translation team to
'~gnome-translation-project' and having some documentation for
translators that this particular app lives in launchpad.  With
Launchpad, they wouldn't need direct access to trunk, but it wouldn't
hurt if they chose to edit directly instead of the web interface.

3) For documentation, a similar situation.  Have some documentation
for them that says, 'for this app, edit docs in this trunk'.  Then
they could directly commit.

-mt