Re: [Evolution] How our minds work (was: Msg Selection)

[Matthew Barnes <mbarnes redhat com>]

On Wed, 2010-06-16 at 16:39 -0430, Patrick O'Callaghan wrote:
> Wish I knew. I'm not a devel and have no insight into how their minds
> work :-) In fact I thought I had filed a BZ report a long time ago but I
> can't seem to find it. Feel free to file it yourself and post the BZ
> number here for others to add comments.

Here's some insight, at least from my perspective:

There are 4698 outstanding bugs on file for Evolution and related
modules, of which 1452 are enhancement requests.  The bug backlog spans
ten years, far longer than most of us have even been on the team.  There
are four, maybe five full-time developers left (myself included) and we
all work for open source companies that have their own products to be
maintained, which takes priority over "upstream" development (which, I
think it's safe to say, we all prefer doing).  I'd say at least half of
the roughly one million lines of the code we're maintaining was written
by developers no longer on the team.

When I have time for upstream development and I'm not already engrossed
in some mini-project for an upcoming release [1], I turn to my "bugs"
folder which holds emails Bugzilla sends me when a new bug is filed or
an existing one is updated.  The mails are sorted by date and I tend to
pick from the top, which means new bugs and noisy bugs tend to get my
time and attention.  Bugs that aren't resolved immediately and go silent
usually get lost in the stack as new bugs stream in: out-of-sight means
out-of-mind.

I think my work flow is fairly typical of all of us.

Best way to get our time and attention is to add constructive comments
to the bug.  Evolution being an open source project obviously source
code patches are ideal, but also helpful are screen shots, click by
click reproducer steps, complete gdb back traces or valgrind logs (for
the more technically savvy reporters)... and for enhancements: UI mock
ups (even if hand-drawn and scanned), algorithmic steps, thinking
through corner cases... basically anything that makes the bug easier to
solve.  Or just ask what you can do to help.

It doesn't guarantee an immediate response -- we're all swamped -- but
it at least puts the bug back on top of our "bugs" folder where we're
more likely to flag it to come back to later.

What not to do:

- Post obnoxious or nagging comments about the bug not being fixed yet.

- Post "me too" comments, especially of the form "I still see this bug
  in $SOME_UNSUPPORTED_VERSION".  If you're not running at least the
  latest stable release (currently 2.30.1), don't bother commenting.

- Post the same stack trace over and over.  As long as the first trace
  has all the debugging info we need, you're good.  If we need another
  trace, we'll ask.

- Raise a bug's priority or severity setting in hopes of getting our
  attention.  Those fields are meaningless to us for the most part
  precisely because anyone can come along and change them.

I hope this is somewhat helpful or enlightening.


[1] http://live.gnome.org/Evolution/Planning30