Re: Splitting GNOME Games

["Jason D. Clinton" <me jasonclinton com>]

On Sat, Oct 29, 2011 at 07:20, Robert Ancell <robert ancell gmail com> wrote:
> I've heard it was decided that GNOME Games would be split, but I think
> I missed the memo somewhere.  Shall we confirm / deny such rumours?

It was proposed by the Red Hat Desktop Team at Boston Summit 2010. I
thought it was a good idea but didn't get around to it again until an
opportunity arose to split off Aisleriot. That thread was the only
discussion among us and we didn't have any dissent so that's the plan
I think we're currently wanting to follow.


> - Ubuntu has been delivering the games split for some time with no
> problems.  It was often requested by users.
> - Debian has recently split their packages based on the assumption
> that we are splitting upstream.

Fedora too.


> - The biggest blocker to splitting is libgames-support - anyone got
> any plans for that?

I think that the consensus was to push stable API's in to a stable
shared object (thinking audio playback) and leave the "in flux" stuff
as bits that get copied around until they stabilize.


> If we split, we need to define what the "GNOME Games" team is.  I
> propose that we are a team that maintains a set of "good quality"
> games for GNOME.  I suspect the split games will give us some good
> options:
> - Adding in new games as technology changes
> - Dropping games that are a support headache
> - Keeping the team healthy by bringing in new people
>
> My guess is the release process wont be significantly harder that a
> simple 'for game in a b c d ; do cd $game; make distcheck ; cd -;
> done.  What do our releasers think?

I see each module having a sole maintainer; that is, we would divvy up
what we are collectively maintaining now with each of us active
maintainers taking one or two high profile, active development games
and a handful of stable, un-changing games. There are many games that
rarely see any changes and they simple would get no releases if there
aren't any translation updates.

If the old, un-changing games rely on the stable API provided by the
shared object, the maintenance burden of those legacy games should be
essentially zero and those would become prime real estate for new
blood to come in to GNOME and pick up something and run with it.