Re: Modulesets Reorganization

[Matej Urban <matej urban gmail com>]

Ok, since you dragged i18n inside, let me add a few of my thoughts
from non strict devel side.

1. Reorganization is a must! Maybe a bit wider than proposed, but the
path is right. I'd fork every moduleset to Core and Extra.
- Desktop Apps Core (obviously the core, simpler apps that do the task) *
- Desktop Apps Extra (banshee and rhythmbox and lalala)**
- Desktop Platform Core
- Desktop Platform Extra
- System Platform Core
- System Platform Extra
+
- GNOME Plugins (common plugin development environment for all GNOME apps)

** Since "one of a kind in the system" is the only logical idea, there
are cases, where this is not the case. One failed for example is "two
panel nautilus view" which is mistakenly identified as "twin panel
file management" as in gnome-commander. Thou not developed enough
gnome-commander is not an alternative to Nautilus, but alternative to
file management, hence should be in Core.
* basically guessing which one comparing banshee and rhythmbox is
better is up to the user. Desktop CORE should by default use something
simpler (like Exaile in this case (not on GNOME))". Users that KNOW
what they want, can get banshee or rhythmbox through repos. At the
moment one of this progs is installed by default, which naturally
artificially rises it's popularity. This kind of popularity brings
bloat ...

2. Remove projects, that are not hosted by gnome from translation
stats and doc. Gstreamer might me important for numerous apps, but it
is obviously not important enough for GNOME. You probably had noticed
that project based on gnome git get more updates. Just try coping with
TP and you'll know why! For such modules make "Outside" moduleset, not
bound on i18n.
Also remove project not getting attention for more then one year and
put it in archives.

3. Desktop and Platform Core should follow release cycles, "Extra"
should have free hands to decide whether to follow cycles or stay
permanently on development.

4. Development should follow strict structural rules. For example; all
i18n modules use gettext po for UI, which makes it easy to maintain.
Doc section used multiple approaches (see balsa, gbrainy in empathy)
Most projects use .xml (why not tettext po? to make it really
compatible), but these use .page, some use .po ...

5. Start releasing stats (eg gnome stats page) about the project,
developers, translations, users ... Picking one project over the other
many times follows the "development routine". It's also motivating.
This way it is possible to categorize projects and "one true apps" for
core and extra without the flames which one is better.

6. In Extra there should also be the projects that are proposed
through distros. So gnome should be an upstream for everything that
follows gnome rules.

7. An incubator is a playground for apps pulling to get to extra,
Extra should follow GNOME rules and practices.

8. GNOME should use common development environment and should set
common programing language and libraries. I never use a program that
needs installing 200MB of deps just to make it run on mono.

Thanks,
Matej