Re: [DRAFT] Modulesets Reorganization

[Andre Klapper <ak-47 gmx net>]

Am Montag, den 19.07.2010, 15:39 +0100 schrieb Lucas Rocha:
> 2010/7/15 Andre Klapper <ak-47 gmx net>:
> > Am Dienstag, den 01.06.2010, 12:57 +0100 schrieb Lucas Rocha:
> >> Here's a new draft with the following changes:
> >
> > Lucas, do you plan to analyze the d-d-l feedback soon and either comment
> > and/or update the reorg proposal?
> 
> I've read the messages on the thread and, to be very honest, I'm not
> sure what would be the best next step right now. The main issue I see
> with the 'no moduleset for apps' proposal is about how to best
> communicate the apps that the i18n and docs teams should focus on. So,
> it seems that keeping a sort of central list of apps we care about is
> important to sync work with the several teams in the community
> (especially docs and i18n). Johannes Schmid's proposal is interesting
> but still keeps an (slightly more flexible) apps moduleset around.
> 
> I'm thinking of working on a proposal for a points-based
> "certification" of apps but honestly I'm not sure there's agreement
> even inside the r-t about this. So, while I think about all that, some
> feedback from other r-t members on this issue would definitely be
> helpful here.

In case of remaining with the old concept we'd have another module
proposal period in 10 days, hence we should come to some conclusion(TM).

If we're all too busy: Maybe Lucas' posting that I quoted here should be
sent to d-d-l so the community can start another round of
bikeshe^W^Wdiscussions.

Points based system: Sounds nice, but who could implement that, and how
long would it take?
I'm pessimistic.


I didn't read all mail on d-d-l again, but in short my current thoughts
are:
Set up a yes/no
Have a collection of "blessed" applications that module maintainers can
apply for inclusion for, at any time of the schedule, on d-d-l.
Call it "GNOME Software Collection" as KDE does and give the community
two weeks to let them check/discuss its fit and GNOMEyness as per
http://live.gnome.org/ReleasePlanning/ModuleProposing .
Have an r-t member to set up a vote after these two weeks and post the
URL in the thread (Ah, uh, a rating system, again! Tweak the board
voting system and allow all foundation members to vote which have read
the post on d-d-l, or use an external website?).
In case of NO, block reproposing for six months.
In case of YES, make it mandatory to follow the GNOME release schedule,
to use GNOME FTP for tarballs (even if it's just copied there), and to
be listed on l10n.gnome.org for translators.
Personally I don't consider using GNOME Git as mandatory, however it
should be recommended (or at least mirrored so documentation team and
translation teams do not have to learn bzr, hg, svn and all the other
evil stuff out there, plus translations can be automatically committed
from l10n.gnome.org once the hook for gnome git is in place).

GNOME r-t will not publish and check SC modules in its releases, it's up
to the community to report build issues or stuff not working well
together. There are bugtrackers for this, or d-d-l for "Your API change
sucks and broke my consumer app", as usual.

On my wishlist, from time to time the SC modules should be (re)checked
for activity as we already have a few dead modules in our stack that I'd
personally love to kick out (e.g. swfdec). Some volunteer could do this
(r-t, or not).


These are my very naive two cents on this which probably miss a lot of
important points and obstacles.

So, what's up, dudes?

andre
-- 
 mailto:ak-47 gmx net | failed
 http://www.iomc.de/  | http://blogs.gnome.org/aklapper