Time to heat up the new modules discussion

So, we need to get the module discussion rolling.  I've read up on
what I can and have written up a summary.  Anyone see anything I
missed or should change before sending on to d-d-l?



Hi everyone,

As per the release schedule (http://live.gnome.org/TwoPointFifteen),
it's time to heat up the module inclusion discussion.  So, time to
flame, argue, etc., etc. this week and see if we can reach consensus.
The release team will try to meet next week about new module decisions
with community input up to then so that the new modules can be
announced in time for module freeze.  We're actually optimistic enough
(deluded enough?) to think we can make that deadline this time.  :)

So, to start of the discussion, the proposed modules AFAIR are:
 * orca (as a replacement to gnopernicus)
 * alacarte
 * gnome-power-manager
 * Tomboy
 * Gtk#

There's one additional issue to address as well:
 * Okay to have desktop modules depend on gtk# bindings?

Here's my biased guess (feel free to dispute) at where things stand:

orca appears to be an uncontroversial choice with strong support, and
which even the gnopernicus team is supporting.  (There have been a
number of threads and lots of comments;
seems like the best overview)

There have not been many comments on alacarte; just a couple notes
that looked like preliminary reviews in the thread where it was
proposed (http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00305.html).
So we definitely need thoughts and comments from the community.

gnome-power-manager seems to have lots of support and it appears it's
getting picked up by all the major distributors (or already has been
for some time now).  Didn't find a clear overview email and there's
been lots of threads.  I guess

Tomboy was proposed here:
Comments were very positive for the most part, but there are gtk#
dependency issues that need to be resolved first (see e.g.

gtk# was proposed here:
There was one big (IMO) issue, mentioned in the thread (namely,
wrapping API which had no stability guarantee)

And the big question:  We currently allow desktop modules to depend on
the pygtk bindings, but no others.  Should we extend that to include
the gtk# ones?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]