Re: [Evolution] a challenge to the developers

[Nick Jenkins <nickpj gmail com>]

> > latest roadmap (http://www.go-evolution.org/Evo2.26) concerns the
> > planning for 2.26. That version was released more than 6 months ago,

There's also:
http://www.go-evolution.org/Evo2.28 and
http://www.go-evolution.org/Evo2.30  (although maybe there weren't
previously links to those pages on the front page?)

Is there some way that Evo users can be given edit privileges on this
wiki? There's certainly updates that can be made to the wiki, e.g.
* From the "Evo2.30" page, the link to bug 255248 can be removed, since
that's been marked as "NOTABUG".
* To the http://www.go-evolution.org/Evo_Future page, I think we should
add a section called "move from threads to GIO" containing what Matthew
wrote explaining the move away from threads to GIO, and the reasoning
behind it. Equally the "Bonobo less Evolution" section can be moved from
the Evo Future page to the Evo2.30 page, and can presumably be marked as
done on that page, as per http://mbarnes.livejournal.com/3367.html

* I also think there's some merit in creating a "Top User bugs" page on
the wiki, where the collective userbase can nominate for each release a
handful of bugs that really annoy them - with the idea that these are
not feature requests, but reproducible crashes or dataloss that occurs
for a large number of users, or behaviour that sufficiently annoys a
large number of users (or to express it as SQL, "SELECT bug_id,
annoyance * num_affected_users AS total_pain_level FROM reported_bugs
ORDER BY total_pain_level DESC LIMIT 5"). I think it's reasonable to
restrict this to a small finite number of items for each release (e.g. 4
or 5 bugs per major stable release) so that it's manageable, with the
debating & deciding of what those 4-5 items are to be done openly on
this list, collectively by Evo's users reaching some kind of broad
consensus. I think it's also reasonable to ask that all suggested bugs
have a bugzilla report, have been experienced by more than one person,
and if at all possible have a reproducible series of steps that can be
followed to demonstrate the bugs.

Let me give an example: My two suggestions for this release cycle would
have been:
1) https://bugzilla.gnome.org/show_bug.cgi?id=599627 - Crash adding a
new task in 2.28 [this bug has since been fixed].
2) Would be this, as per described by Ben Zaborowsky:

> I get many HTML emails and while Evolution takes forever
> (over 5 minutes in many cases) to download and display them,
> Thunderbird
> does so in a second or two.  I believe this is an issue with the way
> Evolution handles network requests and has been a bug for quite some
> time.

... which I believe is otherwise known as
https://bugzilla.gnome.org/show_bug.cgi?id=582591 "Images very slow to
display". (Whilst this bug does not cause dataloss, the resulting
slowness is something that obviously is noticed by and annoys a lot
people, especially with the growing popularity of HTML emails that use
external images, so I think the broadness of its impact justifies this
being considered for a top bug list).

"Brian J. Murrell" wrote:
> I experience "hangs" (i.e. freezes) all of the time.  I send in stack
> traces every time I do.  They just don't lead to anything.

Brian, can you possibly suggest your top (say) 2 bugzilla reports?
Ideally reports that others people have also experienced, that have all
the info that the developers have requested, and that have a
reproducible series of steps (if possible) ? I understand your
frustration, but expressing general non-specific frustration is possibly
not as constructive as nominating the details of a very small number of
the most frustrating bugs you encounter.

I'd encourage everyone to do this, suggesting say 2 bugs (please include
bugzilla links), whilst being positive and constructive about, in the
hope that from this exercise a broad consensus of the top 4-5 most
pain-inflicting bugs will emerge. I think it'd help everyone to get some
clarity on what the worst bugs are.

-- All the best,
Nick.