On Mon, 2009-03-23 at 17:11 -0400, Owen Taylor wrote: > On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote: > > 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. > > 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.
I am sure there will be users that do not like the change in mental model gnome-shell will bring. It would be a shame if those users missed out on the improvements to Metacity (aka mutter). I think whatever development model allows Metacity to ship with a clutter based compositing backend, or an alternative metacity-clutter binary would be best. John > 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 > > > _______________________________________________ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list