Re: splitting up gnome-games

[William Jon McCann <william jon mccann gmail com>]

Hi,

On Mon, Oct 4, 2010 at 11:30 AM, Colin Walters <walters verbum org> wrote:
> Hi,
>
> I'd like to float the idea of splitting up gnome-games upstream into
> separate git modules.  The main rationale is that downstream, we want
> separate binary packages; this is most convenient to do if upstream is
> separate modules.
>
> Having separate binaries would make application installation/removal
> saner, and avoid pulling in the large dependency set of the games as
> one unit.
>
> Also, if there are any other git modules that ship multiple
> applications (i.e. .desktop files and executables), I'd like to see
> that split up too.

I think this makes a lot of sense.  You've already mentioned a few
reasons for why these meta-module constructions are problematic - but
they aren't the only ones.  Meta-modules like gnome-network,
gnome-media, gnome-utils, and even gnome-control-center for a long
time (though for GNOME 3 we've given it a new focus) were very
difficult to maintain and hence very poorly maintained.  There are a
number of reasons for this but one big part of it is that
maintainership was essentially per-submodule.  That really breaks the
maintainer model that we use and there was a bit of tragedy in that
unowned commons space.  Just promote them to full modules and break
out the shared bits into libraries.  It simplifies things a great
deal.  Code responsibilities/duties/blame, git history/branches/tags,
and bug-tracking/patch-review will all be much more straightforward
and clear.

In GNOME 3 we will be bringing app identity into more focus too.
Basically if you are creating a user facing interface you are either
an application or part of the core UX.  That doesn't really match up
very well with the meta-module approach of a loose grouping of
windows/dialogs that (incompletely and loosely) match a certain
category.  We're better off with a one-to-one mapping of module to
application and a type of tagging system to identify the app as a
game, sound or network utility, etc - either in an app store, distro,
or jhbuild.

There may have been valid reasons why meta-modules were convenient in
pre-git days but those reasons no longer apply.

If we find that we don't have a maintainer for a certain submodule
that isn't a reason not to break it out of a meta-module.  That is a
reason to break it out and mark it as unmaintained - or drop it.  As
well as an opportunity for new contributors.

Jon