Chris, that is where I come in. I have a project that I'd like to start after mozilla's 1.0 codebase is API fixed.. to then create a new bugzill a tool.. that will help this problem. I need to learn the programming of the XUL & XML, and probably how all the XPCOM & XPAPPS, Tools & Widgets stuff work.. which hopefully done right, would allow this vision I have to come to fruitation. It will greatly easy bugzilla's problem. I would need to write specs first too. It only exists as a project idea on paper. My current time is taken to help mozilla get to the 1.0 status.. and to download/test as many nightlies as I can for my w2k box. I used to work for a development company where I did a lot of beta testing and I have a degree in CIS. Right now I have a physically intensive labor job which pays really good, yet really wears me down.. and cuts down my time to actually learn more about mozilla. But I am looking for better.. testing code is by far easier than actually writing it and fixing it without codebase knowledge. One area I think that would be helpful, is a download file that mozilla compiles to get everything working on a certain platform, then just telling us to download this problem, write this here.. etc, just shy of distribution of pay-software programs. I just dont have to time to get a machine up and running just so I can spend forever trying to figure out how to get it compile.
-dman84 Chris Hoess wrote: > 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. > >
