Thoughts about the proposed modules

[Olav Vitters <olav bkor dhs org>]

External dependencies
=====================
http://live.gnome.org/TwoPointTwentynine/ExternalDependencies

libdb
already approved


gmime
+1, haven't investigated this much


vala
+1, would enable us to ship only the real source files and skip the
generated .c files



Desktop
=======
http://live.gnome.org/TwoPointTwentynine/Desktop

clutter-core
+1, IF fully uses either GNOME infrastructure, or freedesktop.org
currently git module is on clutter-project.org
Bugzilla is on http://bugzilla.openedhand.com/
--> both need to be changed


couch-db, evolution-couchdb
-1, highly recommended dependency on Mozilla js, other than that I'm
undecided. Seems thought it needed on bigger picture. Thread has
suggestions that it might be reinventing Nepomuk ontologies. How does
this interact with tracker and the stuff KDE is doing?

| "Many people consider e4x
| (http://www.ecma-international.org/publications/standards/Ecma-357.htm)
| to be a feature available in couchdb JS views"
and libseed doesn't have that it seems


dconf
+1, sane settings should be migrated when it makes sense
GNOME 3.0 at 2.32 because of dconf
something about dbus changing, gdbus/dconf not supporting that (fd type)


gnome-packagekit
+1, purely because it will provide a better user experience. Nautilus
can automatically select things to be installed using packagekit. I saw
something similar for file-roller. Being able to rely on packagekit
working on a distro is good.


nautilus-actions
-1, too specific IMO, rather have a better MIME system that also defines
actions like Print, etc


nautilus-sendto
+1, useful


tracker
?, undecided
I should investigate the differences between tracker, couchdb, dconf and
how they all should interact. Haven't done that, so keeping this as
undecided.
There is an outstanding question in the thread regarding
| to sustain it: inotify. inotify is simply not suitable for recursively
| watching $HOME, but Tracker tries that nonetheless. And that is a big
| big failure, it should not do that.

Response from that:
| So we discussed this at the kernel-fixing-bof at GCDS. IIRC we basically
| decided that being able to have a recursive inotify with a new flag was
| the best option. Matthew Garrett was planning on taking the issues that
| we discussed to the kernel developers, so I'm ccing him here for his
| input.


globalmenu
-1, conflicts with gnome-shell
Note: doesn't use GNOME git

-- 
Regards,
Olav