This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have been looking at the quality criteria wiki pages for NB65 and noticed that the number of permitted P3 bugs is now beyond 4000. Although I understand that the code base becomes bigger and bigger as the team adds more features, bouncing up the number of allowed issues by a few hundred for each release is the road to hell, for sure. I am really, for the first time, seriously concerned that, sooner or later, the sheer number of bugs will kill the team and the product (like a government drowned in depth paying only interest rates and no room for improvement left). To get a bit more into detail, I think that the number of issues that the core and the editing tools carry with them should be very low, like no P1 or P2 and only a two-digit number of P3s (instead of 440 or so). Otherwise the other modules won't have a good foundation to rest upon. I'm not sure whether this is or should be my business, but here it is. Otherwise I am very glad how 6.5 comes on. It adds several very welcome features, like being able to define variables, which point to jar locations (that's almost a killer feature). Groovy finally starts to work, PHP editing is useful (although I hate PHP like mad, but I have to cope with it). I also use TCL and shell scripts, now the only missing prominent scripting language is Perl. Best regards, Georg
Another thought is that with this high number of P3s, all bugs with P3 or lower priority become just noise.
I fully agree with every word you wrote here. We are going to redefine Quality Criteria for next NetBeans releases, but it will not be fixed for current release.
Should we change the status then? Or how do you prefer to manage this issue?
If you agree, please confirm the resolution by changing status from RESOLVED to VERIFIED. Thanks a lot!
Great ! Thanks a lot for giving me hope ! Never expected that this bug submission would ever be touched again.
Hm,status: VERIFIED WONTFIX? Is this correct?
(In reply to comment #6) > Hm,status: VERIFIED WONTFIX? Is this correct? Yes, the plan is to change quality criteria from 'number of opened bugs - only' to 'number of opened bugs(will be softer) + path of the critical use without any opened bug'. Give us chance to prepare this for next big release (means not x.x.1).