On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor <otay...@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. _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list