Python to use a non open source bug tracker?

[Tim Peters]

[Giovanni Bajo]
> I understand your concerns, but I have to remember you that most bug reports
> submitted by users go totally ignored for several years, or, better, forever. I
> do not have a correct statistic for this,

Indeed you do not.

> but I'm confident that at least 80% of the RFE or patches filed every week
> is totally ignored, and probably at least 50% of the bugs too.

None are /totally ignored/ -- indeed, at least I see every one as it
comes in.  You might want to change your claim to that no work
obviously visible to you is done on them.  That would be better.  But,
in fact, most bugs and patches are eventually closed, and many that
stay open involve such obscure platform-dependent mysteries that
nobody with sufficient platform expertise to resolve them appears to
exist.  For example, if you'd prefer, I'll assign all bugs and patches
involving threads on HP-UX to you from now on ;-)

These are the actual stats as of a few minutes ago:

Bugs:  938 open of 7169 total ~= 87% closed
Patches:  429 open of 3846 total ~= 89% closed
Feature Requests:  240 open of 479 total ~= 50% closed

> I think there is a much bigger problem here wrt QOS.

Well, you're confident that 80% of patches are ignored.  In reality,
89% of all patches ever submitted have been pursued to final
resolution.  Call me a stickler for detail, but something just doesn't
jibe there to my eyes ;-)

There's an easy way to improve these percentages dramatically,
although they're not bad as-is:  run thru them and close every one
that isn't entirely clear.  For example, reject every feature request,
close every patch that changes visible behavior not /clearly/ fixing a
bona fide bug, and close every "bug report" that's really a feature
request or random "but Perl/Ruby/PHP doesn't do it this way" complaint
in disguise.

The Python developers tend to keep a report open if there's a scant
non-zero chance that somebody, someday, might appear who's motivated
enough to make something of it.  If the goal was instead to make the
percentages "look good", they could easily and justifiably be
dramatically "improved" before today ends.

For example, the oldest patch open today is a speculative
implementation of rational numbers for Python.  This is really a
feature request in disguise, and has very little chance-- but not /no/
chance --of ever being accepted.  The oldest bug open today is from 6
years ago, and looks like an easy-to-answer /question/ about the
semantics of regular expressions in Python 1.6.  I could take time to
close that one now, but is that a /good/  use of time?  Yes, but, at
the moment, even finishing this reply seems to be a /better/ use of my
time -- and after that, I'm going to get something to eat ;-)

Note that I don't mean to claim that turnaround time on bugs and
patches is ideal.  To the contrary, if it's /my/ bug or patch I'm
looking at it, turnaround time sucks, and if you're looking at yours,
likewise for you.  That's what happens when there are thousands of
"you"s and a handful of "them"s, all of the latter volunteering "spare
time".

OTOH, turnaround time on Python bugs classified as critical is superb.