Metacity, Mutter, GNOME Shell, GNOME-2.28

[Owen Taylor <otaylor redhat com>]

Now that the GNOME-2.27 cycle is beginning, I'd like to come up with 
a definitive plan for how we are going to be developing the Metacity
codebase in the context of Mutter and gnome-shell.

To review the current situation:

 - Metacity is developed in GNOME svn by Thomas Thurman and others. 
   This version has some not-very-maintained RENDER compositing support,
   but is mostly the old classic WM we know and love.
   
 - Intel has a branch of metacity (called Mutter or metacity-clutter) 
   that virtualizes compositing to support either RENDER (not maintained
   or tested) or GL and Clutter. This installs as 'metacity' and is
   cannot be parallel installed with normal metacity.
   
 - gnome-shell has its own private Mutter branch (on my personal server). 
   Most changes we made have been merged into the Mutter branch and
   in some cases metacity, but there are some unmerged changes related,
   in particular, to custom keybindings and gobject-introspection 
   support.
   
   gnome-shell is set up as a Mutter plugin that is largely written in 
   Javascript and talks to Metacity and to libraries via 
   gobject-introspection. The 'gnome-shell' executable is a Python 
   wrapper script that runs metacity --mutter-plugins=gnome-shell.
   
I have two strong goals for this development cycle; the first is that
there is a centralized location for development of the Metacity+Clutter
codebase, and that centralized location is in GNOME version control.
The second is that when GNOME-2.28 is released users can install gnome-shell
as part of their normal system and chose between it and normal Metacity.

With that in mind, there are a couple of approaches that could be taken:

1) The Mutter and gnome-shell changes could be folded back into normal
metacity; the goal of being able to run a normal uncomposited desktop
for GNOME-2.28 would likely require keeping the dual composited and
non-composited code-paths. These code paths exist currently in mutter, 
but aren't that well tested, are a bit of a pain to maintain and make 
some types  of changes distinctly harder. There's a risk that we'd 
destabilize non-composited Metacity without providing any benefits.

2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
etc. Presumably, the internals would stay Meta*) and imported into GNOME
version control independently of metacity. The uncomposited and RENDER 
code paths would gradually be removed leaving just a Clutter based WM/CM.
The main disadvantage of this approach is that any ongoing maintenance 
of Metacity would not feed from or to this project automatically.

3) The source code could be imported into gnome-shell, the Mutter plugin
system removed, and the use of Javascript hard-coded. Customization/extension
would be done as Javascript extensions, which could conceivably entirely
replace the gnome-shell UI with something else. An advantage here is that
over time, the core Window management logic could be gradually rewritten
in Javascript and the C core stripped down.

Of these alternatives, while I have some fondness for the third approach,
the second seems most immediately practical. There's a development
philosophy that will help keep it closer to what we could achieve with
the third approach, which is to see the plugin system as only a loader:
once the plugin is loaded it talks directly to the Metacity core, which
is extended as necessary. (Things have been moving in this direction
already; it's become easier to hook into Metacity now that the core objects
are largely GObject-ified allowing signals and properties.)

If people agree with that (better ideas than any of the above also 
appreciated!) then we can move almost immediately. Nobody would be 
forced to switch from the current metacity-clutter repository, of course.
Mechanical question of the transition would include:

 - Do we want to import Mutter as it exists now, and evolve from
   that, keeping all the version control history, or do we want to
   break it up, review it, remove dead ends (like the multiple 
   compositor backends) and commit it as a fresh patch sequence.
   The second would be an enormous amount of work, and probably
   not worth it.
   
 - If we import Mutter as it exists now, do we import it literally,
   or do we convert Metacity using the git => svn import scripts,
   then rebase Mutter on top of that. I think the quality of the
   latter is considerably better and would recommend that. (And
   do we want historical maintenance branches of Metacity in the
   Mutter repository? I think not.)
   
 - What commit policies do we have for the Mutter module? I'm thinking
   that we go pretty wide open but with the requirement that every
   not-absolutely-trivial change needs one review.
 
 So, that's my thinking. Feedback appreciated.
 
 - Owen