Re: Memory consumption bugs - BZ keyword?



Uh, so, I was writing a response, and then noticed that Elijah had
responded already, and, uh, yeah. Everything he said, basically
exactly :) I'm fine with renaming purify to memory and letting things
go from there.
Luis

On Wed, 2 Mar 2005 20:47:25 -0700, Elijah Newren <newren gmail com> wrote:
> 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
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]