Re: some background on bugfixing in NetBeans
Tom Wheeler <[email protected]> Sat, 24 Sep 2011 11:34:04 -0500
| Newsgroups | gmane.comp.java.netbeans.general |
|---|---|
| Message-ID | <CAPsQDD+dwkaYj2tE7Qn8PgnZPNcVdWoteMASnMa6MDfGqBv0EA@mail.gmail.com> |
I want to amplify a few points from John's message: - Issues that describe the problem well get more attention - Issues that come with a patch of good quality get even more attention In other words, I have found by making life easier for the NetBeans engineer who will ultimately push the change to production (because I've described specifically how to reproduce the problem and submitted a patch to fix it), the issue is more likely to get fixed. However, there are bugfixes and there are enhancements. Both are tracked in the same system (IssueZilla). I think one continued area of frustration is that the process for which features are chosen for a particular NetBeans release is totally opaque to the community (i.e. anyone not working for Oracle). For example, I don't think anyone understands what effect, if any, voting for an issue in IssueZilla has. I also don't really know how to set the priority for an issue. IIRC, there used to be a nice set of criteria in IssueZilla, like P1="severe problem with no known workaround" and P5="minor cosmetic problem". Now there's just a rather unhelpful explanation "... available priorities range from P1 (most important) to P5 (least important)." Finally, in the days since the NetBeans Governance Board meeting that led to this discussion, I've found a Web site written by a former developer relations person from Google: http://www.developer-support-handbook.org/ and would *strongly* recommend that anyone interested in improving processes related to NetBeans read it. The section on "Issue Tracking" is particularly relevant to this discussion. I'd simply add that the advice it gives could be improved by making it more relevant to an open source project, where there is at least the theoretical possibility that a community member could participate in triage meetings, help develop a product roadmap or fix an issue on his/her own. Being a member of an open source project comes with both rights and responsibilities. On Fri, Sep 23, 2011 at 4:54 PM, John Ceccarelli <[email protected]> wrote: > Hi folks, > > I know there has been some discussion about bugs and some people expressed > frustration that bugs were not being evaluated quickly enough by the NB > team. I put together this email just so that the community can understand > what's happening behind the scenes when a bug lays open without comment for > a long time and what you can do to help. Your feedback is welcome. >... -- Tom Wheeler http://www.tomwheeler.com/