[3003] in Release_7.7_team
Evolution evaluation report
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Oct 9 16:10:52 2001
Date: Tue, 9 Oct 2001 16:10:49 -0400
Message-Id: <200110092010.QAA06965@error-messages.mit.edu>
From: Greg Hudson <ghudson@MIT.EDU>
To: release-team@mit.edu, aui@mit.edu
Here is the result of my experimenting with Evolution. I think I now
have all the information I need about it, and will go back to
experimenting with Balsa and Mahogany.
-----
Evolution probably has the largest amount of outside development
resources behind it at the moment, and is also the easiest to get
working with Kerberos 4 support (because Dan wanted to test it against
the MIT PO servers). I have used Evolution 0.15 (a beta release) for
a week and found it to be fairly usable and have a decent feature set.
It does include a number of features besides mail (a calendar planning
tool, a task list, an address book, and a news feeds tool) which would
likely be welcomed by users but might involve biting off more than we
can chew as far as maintenance and support.
One of the interesting things Evolution supports is automatic GPG
verification of messages. We would have to put GPG into the release
to really take advantage of this feature, though.
Incorporating Evolution into the release would be fairly easy. It
would require a couple of library upgrades and the incorporation of a
few GNOME packages we don't currently have (gnome-print, bonobo,
bonobo-conf, gal, and gtkhtml), some of which would also be required
by Nautilus and possibly other GNOME packages we might become
interested in. There were no major gotchas in the build system,
although I found a couple of minor bugs which needed to be fixed to
get Evolution to compile in our environment. See release-77 [2995]
for details.
I noted the following problems while running Evolution:
1. Sometimes it fails to start up, saying "Cannot initialize the
Ximian Evolution shell: Configuration Database not found". This
problem occurred more often with Evolution 0.14, and seems to be
mostly specific to particular machines (I have observed the
problem with Evolution 0.15, reliably on one machine and very
sporadically on another). The real problem seems to be an
inability to communicate with a subprocess called "wombat". I
suspect a race condition, though it could also be a failure for
wombat to start up on some machines.
2. Sometimes evolution-mail crashes overnight, and it always
displays an error dialog after my tokens expire about inability
to save my mail folder.
3. There did not appear to be a way to configure the fonts used by
Evolution, so it comes out kind of tiny on my 1600x1200 15"
screen. This would not be a problem for Athena machines as long
as we restrict them to 1280x1024 resolution, but it could become
one of many such problems in the long run.
4. Evolution uses many subprocesses which communicate together using
CORBA calls. This makes it difficult to debug even easily
reproduced problems like problem #1 above.
In addition to any necessary bug-fixing (some of which might be
obviated by a production Evolution release), I anticipate we would
need to make the following local modifications to the Evolution source
code base:
1. We would need to add Hesiod support.
2. We would need it to preconfigure itself with appropriate
settings. (Stock evolution pops up a configuration wizard when
it first starts up.)
3. We would need to add a way to configure it to suppress the local
mail folders Evolution creates, in order to make IMAP folders the
only ones in the default setup. (Right now if you don't have
an ~/evolution/local, Evolution creates one for you.)
4. We would need to add MH support, although some of the necessary
code is already present in Evolution.
5. We would eventually need to add krb5 support as well as krb4
support to the IMAP routines, after the MIT PO servers support
it. This is probably not worth doing initially since it's not
easy to test while the MIT PO servers only support krb4.
Here are my estimates of the initial work required, assuming
relatively solid commitment by one developer:
Debugging: 2-6 weeks, 4 likely
Preconfiguration: 1-3 weeks, 1 likely
Suppressing local mail folders: 0.5-2 weeks, 0.5 likely
MH support: 2-4 weeks, 2 likely
Total: 5.5-15 weeks, 7.5 likely
Here's my grade sheet:
Ease of integration: B
Ease of debugging: D (immature code base, difficult to debug)
Features: A (calendaring, tasklist, news, GPG)
Maintenance/support: C (need to support calendaring, tasklist tools)
Overall: C
