Re: Memory consumption bugs - BZ keyword?

[Elijah Newren <newren gmail com>]

On Wed, 02 Mar 2005 21:05:11 -0600, Federico Mena Quintero
<federico ximian com> wrote:
> On Wed, 2005-03-02 at 16:55 -0700, Elijah Newren wrote:
> > On Wed, 2 Mar 2005 11:05:55 -0500, Luis Villa <luis villa gmail com> wrote:
> > > I'd be happier with a tracker bug; a memory keyword will be unused
> > > again in 6-12 months.
> 
> Luis, what do you mean by this?

I'll take a shot at answering this, though I may be totally wrong at
guessing Luis' meaning...  We had (and still somewhat have) far too
many keywords; it was getting to the point that the clutter was
becoming problematic and adding keywords was becoming more harmful
than helpful since it was too hard to track all the things we needed
to do with bugs.  It also turned out that many of the keywords we've
used in the past have been very short-lived.  Honestly, if this memory
keyword turns out to be unused in 6-12 months then I'm against it too.

> > Just a though, but we could add the memory keyword, and then move all
> > bugs under the 'purify' keyword over to this one and nuke purify.
> > Then we have a fairly general keyword for memory problems, whether
> > they be problems found in code review, problems found from running the
> > program for a long time and noticing increasing memory usage, or
> > problems found from various tools such as purify, valgrind, memprof,
> > or whatever.
> 
> Conceptually I like a "memory" keyword better.  Maybe tracker bugs and
> keywords are isomorphic.
> 
> ... is there an easy way to find all the tracker bugs in bugzilla?  That
> would be a good starting point for Gnome-Love contributors and such.

There's a tracker keyword, but it was a victim of the
too-many-keywords thing and very few tracker bugs are marked with that
keyword.  Typically, it seems people put the word "tracker" in the
summary, typically in all-caps and at the front--but definitely not
always.

> Initially I thought that leaks were orthogonal to reducing memory
> consumption in non-leaky apps, but what the hell; they are both just
> bloat from the viewpoint of the user :)

Yup.  :)  Actually, though, my suggestion had three purposes:
  (1) add a keyword useful to certain devs right now without having more
      keywords overall
  (2) try to make sure the meaning of the keyword isn't too narrow (e.g. avoid
      things like having "easy-fix", "HELPWANTED", and "PATCH_NEEDED"
      simultaneously)
  (3) solve the "do we call it 'purify' for legacy purposes or
'valgrind' because
      that's what is really used or something else to cover more general issues
      uncovered by similar tools?" problem

> Luis, you are the bug mastah --- in your experience, do tracker bugs or
> keywords work better for this kind of desktop-wide project?

Note that there's also the status whiteboard, a fairly free-form field
that can be searched on--accessibility have used this for example for
being able to set accessibility priorities different than bug
priorities.

Anyway, I'm biased towards adding the memory keyword if we keep the
broader meaning since I think then it'll continue to be used, and
because then we have a clear path on what to do with the purify
keyword.

Elijah