On Tue, Oct 5, 2010 at 13:44, William Jon McCann <
[email protected]> wrote:

> difficult to maintain and hence very poorly maintained.  There are a
>

We don't have any problems maintaining GNOME Games except when the entire
GTK+ rendering stack gets ripped out from under a 10 year old code base 3
weeks before tarballs are due.


> 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.


We will meet our maintenance responsibilities or the games lacking attention
will be dropped (temporarily).


>  Just promote them to full modules and break
> out the shared bits into libraries.  It simplifies things a great
> deal.


It makes things 10 times more complicated for us.


>  Code responsibilities/duties/blame, git history/branches/tags,

and bug-tracking/patch-review will all be much more straightforward
> and clear.
>

We don't presently have any issues with any of those.


> In GNOME 3 we will be bringing app identity into more focus too.
>

"App identity?"


> 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.
>

GNOME Games will not be splitting for the valid reasons that Andreas and I
have enumerated.

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.


That may happen if it comes down to the wire but it will be marked abandoned
as there will be no way to build it without libgnome-games which will not be
a separate public library. I *really* don't want to drop anything, though.
We already know that the games remaining have some hard-core fans.
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Reply via email to