Re: [Evolution] a challenge to the developers

[Chenthill <pchenthill novell com>]

On Tue, 2009-11-17 at 11:07 +1100, Nick Jenkins wrote:
> > > 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".
We have decided to move the wiki from go-evolution.org to
live.gnome.org.  With that you would be able
to edit the list items. Perhaps another agenda item to discuss during
this week's community meeting. 

> * 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
Though the main task is compelete, we have kept the task alive to get
the regressions fixed.

Matt, would be good to have the summary updated ..

> * 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.
It would be best to handle the choice of the bugs using bugzilla.
Normally we choose the bugs based on the amount of duplicates and based
on the severity. Since there are huge number of bugs,  it would be best
if bug master produces us the list of bugs which needs to be looked
at...

It would be hard to even debate/discuss on the selected bugs if
interested users start discussing couple of bugs. The best option left
for us now is to go with our bug master. We would be sharing the list of
issues as I have already sent the list as part of the agenda for the
coming community meeting to improve the list moving forward..

- Chenthill.
> -- All the best,
> Nick.
>
> _______________________________________________
> Evolution-list mailing list
> Evolution-list gnome org
> http://mail.gnome.org/mailman/listinfo/evolution-list