[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. -- http://mail.python.org/mailman/listinfo/python-list
