Re: some background on bugfixing in NetBeans

The intent was to send this to nbdiscuss, as that is the correct forum 
for these types of discussions. I may put it up on the wiki as well.

-J

On 9/26/2011 3:21 PM, John Yeary wrote:
> Is the intent to send out this message to all the forums, post on 
> NetBeans site, both?
>
> Sent from my iPhone
>
> On Sep 23, 2011, at 17:54, John Ceccarelli 
> <[email protected] 
> <mailto:[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.
>> *
>> Why Hasn't My Bug Been Fixed?*
>>
>> "I went through all the trouble of filing a great bug report and it's 
>> just been sitting there for months with no action, or it was closed 
>> out by the engineer. What's going on?"
>>
>> The NetBeans team values your hard work in providing us feedback and 
>> reproducible test cases for bugs. In most cases, we address your bugs 
>> individually. But in some cases, there can be no action on your bug 
>> or an action you don't agree with. Here are a few reasons why this 
>> could happen, and some things you can do about it.
>>
>> *Not Enough Time*
>>
>> The simple fact is that, like most large software products, we do not 
>> have enough time to evaluate and resolve all of the bugs in any given 
>> release. The NetBeans team concentrates on the P1s and P2s in any 
>> given release then fixes as many of the P3s as we can before it's 
>> time to ship. That means that some P3s get carried along from release 
>> to release.
>>
>> *We Can't Reproduce *
>>
>> This is the number one cause of bugs not being addressed or being 
>> closed out. If we can't reproduce it locally, then it's very hard for 
>> us to fix it. However, we often have enough evidence that the problem 
>> does exist. Thus we leave the bug open to gather duplicates and other 
>> information in the hopes that some new reporter can help us reproduce it.
>>
>> *Not in Stabilization Phase Yet*
>>
>> Often we're in the middle of new feature development, while the bug 
>> stabilization phase comes a few months later. This can lead to your 
>> bug not being commented on for a long time.
>>
>> *Not Actively Developed Functionality*
>>
>> When NetBeans tooling for a certain technology is mature and the 
>> technology itself is not changing often, we try to make as few 
>> changes as possible in that area, since any change would require 
>> heavy retesting of the whole area. This can lead to bugs staying open 
>> in these areas for a long time.
>>
>> *The Problem Isn't an Easy One to Solve*
>>
>> Some problems, while valid problems, are relatively minor but would 
>> require large rewrites of the present infrastructure. For example, 
>> line wrap in the editor was a seemingly simple change that we had to 
>> do a substantial editor rewrite to enable. But we left the bug open 
>> to track the votes and user interest in this feature until we decided 
>> it was time to implement it.
>>
>> Other bug reports are for issues that we work on continuously but can 
>> still improve. The performance of project scanning is one such area. 
>> We often leave these bugs open because they contain valuable 
>> information on reproducing performance issues. But that doesn't mean 
>> no work is being done on those issues.
>>
>> *The Proposed Solution Isn't Proper or Realistic*
>>
>> People often file issues because they would like to see the UI 
>> designed a certain way (for example, change a keyboard shortcut for a 
>> frequently used action). Others propose solutions to problems that 
>> are not realistic (make project scanning optional - NetBeans can't 
>> provide any IDE functionality for a project until it's scanned the 
>> project and knows what's in there!). In these cases, NetBeans 
>> engineers will close out your bugs as INVALID or WONTFIX.
>>
>> *To Close or Not to Close? That Is the Question!*
>>
>> So what's better? To leave a bunch of bugs that you know you have no 
>> intention of working on open for release after release, or to close 
>> them out as WONTFIX, even if they are valid issues, and have the bug 
>> database be a closer reflection of what you are currently working on? 
>> In the past, we've just left everything open, but lately we have 
>> started closing out old bugs that have not seen any changes in 
>> several releases. If your bug gets closed out and you can still 
>> reproduce it, feel free to reopen the bug. This helps us to confirm 
>> that the bug is still valid.
>>
>> *What Can I Do?*
>>
>> The easiest thing is to just add a comment to the bug and ask if 
>> there has been any progress. That will often (but not always) get the 
>> responsible engineer's attention and elicit a response. Other things 
>> you can do are:
>>
>> * Be specific! The more you can help the engineer reproduce the 
>> problem, the higher chance that it will get fixed.
>> * Vote on the issue. It's not a guarantee, but it is used in our 
>> decisions on what to work on
>> * If you suggested a UI change that was rejected by the team, try 
>> configuring the UI to implement your change through settings and 
>> macros, or try writing a module that implements the UI change for you.
>> * Submit a patch. Check out the First Patch program for help.
>> * Take it up with the NetBeans Governance Board. If you have 
>> submitted a patch and there is a disagreement on whether or not to 
>> integrate it, you can ask the NetBeans Governance Board to mediate.
>>