Re: Metacity, Mutter, GNOME Shell, GNOME-2.28

[Colin Walters <walters verbum org>]

On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor <otaylor redhat com> wrote:
>
> 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.

I'd like to toss in here:

4)
 o Import "mutter" as a "branch" of metacity
 o When built, it installs its binary by default by default as
"metacity-compositor"
 o We share a common GConf schema subset (even if e.g. compositor has
a few more keys)
 o We share the bugzilla name "metacity"
 o Replay some of the non-compositing changes like GObject-ification
and introspection support on to mainline to reduce the divergence

There are some tradeoffs here, but I'd like to avoid creating a
distinct mutter "brand" and forking the GConf keys, even if the
display technology is changing a lot.