[Python-Dev] topics I plan to discuss at the language summit

[R. David Murray]

On Tue, 12 Jan 2010 22:10:14 +1000, Nick Coghlan <ncoghlan at gmail.com> wrote:
> There are actually a whole host of reasons issues can stagnate:
> - a feature request may seem reasonable (hence it doesn't get rejected
> outright), but the right API may not be clear (hence it doesn't get
> implemented in the near term)
> - a patch may be reviewed and found to have significant defects (or
> simply be overreaching the stated goal) but the original patch poster
> loses interest after meeting resistance in their ambition to fix
> something that is "obviously" broken
> - a problem may simply be hard to fix in a backwards compatible way (or
> even at all!)

I would add:

- a patch is reviewed but the reviewer requests a second opinion before
  committing, which never arrives, and the original reviewer forgets
  about the issue.

I have occasionally observed apparently moribund issues spring to life
and get resolved when a triage person does something as simple as updating
the releases to which an issue applies.

> Ultimately it boils down to Antoine's two categories (lack of interest
> and lack of relevant expertise to make a final decision) but there are a
> lot of different ways to get into those two buckets.

There's a third bucket here: lack of time.  Sometimes there is interest
and expertise, but no time.  Worse, sometimes we end up waiting on the
person with the expertise and interest but no time, when someone else
with somewhat less expertise but more time should just go ahead and do
the commit.  (*That* one should be fixable.)

> Because we aren't ruthless about pruning those kinds of issues out of
> the tracker they're the ones that are going to accumulate over time.

Another other category that hangs around in the tracker is items for
which there simply isn't a consensus.  I suppose those could be brought
to python-dev for a final decision if someone wanted to tackle that task.

And I don't think it is a lack of ruthlessness.  I think it is the current
community consensus that we leave these issues open in the tracker in
case someone does come along and want to deal with them. (*)

> I'd actually be interested to know what the issue stats are like when
> RFEs are excluded and when the search is limited to the items flagged as
> 'easy'. If easy bug fix issues are taking a long time to get closed than
> that would bother me a lot more than RFEs that sit on the tracker for
> years.

I'd also be interested to know what the average and median lifetime
of closed bug reports is.  Not the metrics for open issues, but the
metrics for closed ones.  My theory is that we close a lot of bugs fairly
promptly, but the ones in the above categories make the average age of
*open* issues high.

--
R. David Murray                                      www.bitdance.com
Business Process Automation - Network/Server Management - Routers/Firewalls

(*) For example, I'm currently going through all the open issues
relating to the email package, and some of them are pretty darn
old, yet still have useful content.