Hi, On Mon, Oct 4, 2010 at 11:30 AM, Colin Walters <[email protected]> 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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
