Re: [Evolution] a challenge to the developers



On Mon, 2009-11-16 at 08:24 -0430, Patrick O'Callaghan wrote:
It would be nice to hear someone on the devel team say what the worst
bugs are thought to be and explain what they propose to do about them.
Unfortunately the various roadmaps, version by version, say nothing
about prioritizing bugs, only about adding features.

It's also rather depressing to see that the latest Release Notes are for
2.24 (http://projects.gnome.org/evolution/documentation.shtml) and the
latest roadmap (http://www.go-evolution.org/Evo2.26) concerns the
planning for 2.26. That version was released more than 6 months ago, so
the planning must have happened several months earlier. It's hard to
avoid the impression that Evo is struggling. I really hope I'm wrong.

I would say that we are struggling in terms of manpower.  Thanks to
layoffs and personnel turnover within Novell, the development team is
now smaller than it's ever been.  (Though it looks like we're gaining a
few contributors over at Intel's Moblin team.)

The outdated web page is my fault -- I'll try to get that updated soon.
And I only just realized that I finally have editing permissions on the
front page of the wiki, so I've updated the planning page link (though
admittedly those pages are not nearly as detailed or up-to-date as they
should be -- that's something we need to address since a lot of users
look to that page to know what's cooking for the next release).

As for bugs, we've been doing a better job this cycle at identifying
important bugs and focusing resources on them.  Akhil Laddha, our
resident bug master, has begun collecting critical issues for us to
review in our weekly IRC meetings.

Stepping back for a moment from our current bug list, there are still
some very deeply rooted architectural issues in Evolution that need to
be dealt with for the project to remain relevant as we enter into the
GNOME 3 era.

Bonobo was one of them.  I've already written at length about why its
removal was necessary [1], but in a nutshell: it's not a feature, it's
not about eye-candy, and it's not even directly for the user's benefit.
It's for ours.  It replaced an old and crumbling foundation with a new
and stronger one.  It also happened to fix over 60 bugs, but that was
mostly a side-effect.

The next deeply rooted issue to address, in my view, is our overuse of
threads.  Threads are a poor mechanism for concurrent I/O.  They're
wildly non-deterministic and are constantly working against you to cause
data corruption and deadlocks.  As a developer your job is to use locks
and synchronization variables to try and tame the things enough that
they don't tear your program apart.  But you have to be very careful
with them, and even then things still gets very complex very quickly.

Evolution -loves- threads.  We use them everywhere.  And honestly, I
think a lot of the networking, deadlock and overall stability issues
both now and over the years can be traced back to this.  We need to
ditch the threads.

For those familiar with GNOME's development platform, GNOME finally has
a decent library for disk and networking I/O in GIO [2].  GIO promotes
asynchronous I/O via an application's main loop (the same main loop that
drives the graphical interface and device input) over thread-based I/O.

Evolution needs to embrace this approach from top to bottom, but that
will mean redesigning a lot of our core libraries.  And that, like the
Bonobo removal, is going to be another major project.  But I'm convinced
it will put us in a much stronger position going forward, and will
probably solve a lot of the deadlock and data corruption issues being
reported.

This is a long-term vision.  We'll continue fixing the symptoms that
users report, but we also need to treat the disease that's at the heart
of these bugs if Evolution is ever going to turn its reputation around.

Matthew Barnes


[1] http://mbarnes.livejournal.com/2606.html
[2] http://library.gnome.org/devel/gio/stable/




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