In article <[EMAIL PROTECTED]>, Ortwin Glück wrote: > Looking at the bug statistics at > > >http://bugzilla.mozilla.org/reports.cgi?product=-All-&output=show_chart&datasets=NEW%3A&datasets=ASSIGNED%3A&datasets=REOPENED%3A&datasets=UNCONFIRMED%3A&links=1&banner=1 > > Bugs are taking over! > > Fact: > The number of bugs is now three times as high as half a year ago: over > 12,000 open bugs! > > Are Mozilla developers creating more bugs than they (can ever) fix? > Where is this going to end?
I think that your assertion is incorrect (as other posters have stated), but let me try to provide some justification. If the increase in bug count was indicative of truly new bugs, i.e., regressions, we would indeed be in trouble. Having done QA on and off in the Layout component for over a year, the problem is mostly one of design flaws in Bugzilla, rather than the Mozilla code. To wit: 1) It is difficult to find specific bugs in Bugzilla. Whether this is a problem with the search interface, or whether we need to be somehow tagging bugs with a larger and greater variety of keywords (perhaps in a semi-automatic way), I can't exactly say; but as it stands, there's probably a reasonable percentage of duplicate bugs buried in there that no one has spotted. 2) There are a lot of ueseless bugs in Bugzilla. Component owners may file bugs as reminders to themselves to reorganize some data structure later, be sidelined by other work, and the bug may drift on through another owner or two long after the data structure is removed from the code. There are enhancements ranging from the reasonable to the utterly unlikely. There are bugs reported and confirmed a year ago on a then-current build that have never been reproduced again... Basically, I would say that while there are certainly regressions, they are being kept at a manageable level, based on what I've seen. However, given the current state of Bugzilla, I can't compile the statistics to prove it. Unfortunately, the current Bugzilla model, with default assignees and QA contacts, is a serious roadblock to fixing this problem. While this is still holding up in some of the smaller components, in large components like layout, the system has utterly collapsed. What is needed to remedy it is some significant changes in Bugzilla's concepts of state, introducing more levels of granularity between UNCONFIRMED and CONFIRMED. Bugs would drop into here until QA personnel and the bug reporter could clearly determine the cause of the problem (i.e., "the margin on this <td> is wrong" rather than "this page doesn't work") and produce a consistently reproducible testcase. Only after this was done would the bugs be marked as "real" bugs and assigned or chosen by programmers. I believe that a system along these lines would produce bug statistics that more accurately reflected the state of the product. -- Chris Hoess
