Move Evolution to Extras?

[David Woodhouse]

On Tue, 2006-04-04 at 10:15 -0300, Pedro Fernandes Macedo wrote:
> Add then bug #336074 (RH #167805) to the previous one and you get a
> pretty bad situation where you check all your old folders even when
> you dont want them and you do it using the slowest method possible
> (the above bug).
> 
> Those two can be a bit problematic if you have an IMAP server that is
> outside of your network and your link is a bit overloaded or you have
> a lot of e-mail stored on the server.

To put real numbers to 'a bit problematic'...

Even after I fixed #336074 (RH #167805 -- filed September 2005, still in
NEW state), it took two hours to start up for the first time when it was
working over my DSL line, and it even took 23 minutes to start up when
it was here in my house and connected via GigE to the IMAP server.

It fetches every header for every mail in every active folder -- and
without my patch for #336074 that would have been every folder in the
system, not just the active folders. Whenever it reconnects, it updates
its cache by downloading all new headers from the server. The cache in
my ~/.evolution directory is about half a gigabyte, most of which is
unnecessary.

Each time it checks for new mail, it fetches the flags for every mail in
every (active) folder -- instead of just issuing a single STATUS command
for each (active) folder.

For an idea of its runtime performance, see the graph from by my ISP: 
http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-2.png

You can see when it was started up (remotely) at about 7:30 on Saturday
night, and stopped just after 10:15 on Sunday morning. The periodic mail
check is set to something like 12 minute intervals -- 5 checks an hour.

You can see my _original_ remote startup at about 7pm on the first day
of http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-elided.png
along with the result on the latency for the next few days till it was
killed (with a brief respite on the second day because I'd killed it to
play with a potential fix). Again, that's with #336074 fixed so it's
doing about 12 times less work than the 'stock' evolution packages would
be doing.

The ISP didn't have the shiny new graphs in place back then, so it
didn't show upload and download bandwidth -- but it's still fairly
clear.

Then there's the one which makes it unusable for people who use wu-imapd
and check 'show only subscribed folders' -- that's BZ #181805.

These are probably the minimal fixes we need to turn it from an unusable
pile of crap into just a suboptimal pile of crap:
http://david.woodhou.se/what-evo-did-to-my-bandwidth-graph-2.png

Gr. No, that's
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145314 in action.
Let's try that again without trying to just select-and-middle-click like
we can in any non-broken X application...

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181805
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183219
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167805
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161397

-- 
dwmw2