ticket status report

[Luke Schierer]

On Wed, Sep 12, 2007 at 01:29:22PM -0700, Sean Egan wrote:
> On 9/12/07, Luke Schierer <lschiere at pidgin.im> wrote:
> > I would ask everyone to try to devote at least a few hours in the days
> > following our 2.2.0 release to the 100 oldest tickets.  Lets close those
> > that are unfixable for lack of information, and the feature requests
> > that time is proving we won't get around to implementing short of a
> > patch.  If we can close a signficant number of these, I feel confident
> > that we will be rolling over far fewer tickets each release.
> 
> I'd be glad to do this. Do you mean the oldest 100 ticket in the 2.2.1
> milestone? Or the oldest 100 total.

The two are nearly identical, particularly if you mentally filter out
those related to Trac or the webpage.  I'd be estatic with either, but
for simplicity's sake, lets say in the 2.2.1 milestone.

> 
> > You will have noticed that I have stopped attempting to to assign
> > tickets to mile stones.  It simply isn't worth it, when most of the
> > tickets attached to our previous mile stones have been passed over in
> > favor of new work and newer bugs.  What can I do to make it easier to
> > close *old* tickets?
> 
> I think the problem is that age isn't a good measure of importance.
> Most of the older bugs are minor impact and non-trivial to fix (yes
> still valid); I'd much rather fix 100 more important bugs than 100
> older ones.

To an extent that is true, certainly.  On the other hand, fixing them
will pave the way for finding and fixing more important issues both in
that the tracker will remain (relatively) easy to find things in, and in
that it will help promote familiarity with *all* of the code base, and
not just the parts we have been most heavily working on lately.

> 
> I feel bad closing a perfectly valid bug as "wontfix," but we can
> definitely make inroads with just "invalid" and "worksforme"

I agree, it is distasteful to close valid bugs as anything other than
fixed.  Still, I suspect there are many of them that we can't fix with
the eixsting info on them.  

luke