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

[Owen Taylor <otaylor redhat com>]

On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote:
> 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.

A branch in the (future) Metacity git repository is an interesting idea,
in that it allows changes to be moved somewhat more conveniently between
the trees.

But it could also be confusing, and unless you are going to keep on
merging Metacity wholesale into mutter, there's not a big advantage in
having them in the same repository. 'git cherry-pick' has no special
intelligence over just applying a patch.

How would you see packaging and installation working with your scheme?
I don't see how different programs (metacity and metacity-clutter) could
share the same GConf schema keys.

- Owen