On 09/24/2013 07:17 PM, Jonathan Kamens wrote:
As Michael Schwendt has pointed out, NEW implies neither that the bug hasn't been looked at nor that there has been no activity on it.

Russ Herrold is also correct: if bugs are not being looked at, then that's not the fault of the bug-tracking system, it's the fault of the people who are supposed to be looking at the bugs.

Drawing conclusions from a single package is rigging the game, since what we're discussing is that some packages are maintained better than others.

Looking at F18 is rigging the game, because a package maintainer may have (reasonably) stopped looking at F18 bugs when F19 came out if s/he knows that F19 has a new version which fixes significant bugs.

Having said all that, let's assume, for the sake of argument, that NEW bugs haven't been looked at or responded to, and try to answer the question of what percentage of Fedora bugs aren't being looked at or responded to in a reasonable amount of time. My methodology is to look at the total of all Fedora bugs filed between one and two months ago (to limit the scope of the problem -- otherwise you're just dealing with too many bugs) and then to look at how many bugs within that same time period are in state NEW.

There are 2,129 NEW Fedora bugs and 5,199 total Fedora bugs filed between 2013-07-24 and 2013-08-24. That's only 40% of the total number of bugs, which disproves assertion that the majority of bugs aren't being dealt with. If we go back a month earlier, from 2013-06-24 to 2013-07-24, there are 1,715 NEW bugs out of 3,932 total bugs, i.e., 43%. Still not the majority. A month earlier than that, 1,407 out of 3,804 = 36%. Still not the majority.

I entirely agree with you that it would be better if those percentages were lower. But driving those numbers is not the end goal. The end goal is to improve the quality of Fedora as much as we can with the resources we have, and I (and many others, clearly) don't believe that no longer tracking Fedora bugs in RHBZ will accomplish that.

Working directly with upstream might improve it ( we ofcourse dont know until we actually try that ) since it will cut out the middle man ( the packager ) or give the upstream maintainer ( if he's the middle man ) more time to work on the bug discuss and pass it's patch through upstream ( which needs to be done in most cases anyway ).

JBG