Re: some background on bugfixing in NetBeans

Hello All,

I think that Jirka is right. WONTFIX is a valid option. There are situations
that warrant it. There are situations where it would be impossible to
implement, or that compared with alternatives, you take a different path.

Also no matter how much someone wants a "matter transporter", NetBeans is
not going to have it. Yes, I know it is a little absurd, but it makes the
point.

Obviously, no one wants to hurt someone's feelings, but I think it is going
to happen. It is a fact of life.

 I would suggest that a close with a WONTFIX should have a narrative about
why it won't be fixed. It does not have to be long.

For example, "the module in question is no longer supported, and this issue
is being closed as WONTIFIX". Short and to the point.

John

2011/9/29 Jiří Kovalský <[email protected]>

> Robert,
>
>   while I understand how frustrating closing a bug as WONTFIX could be for
> its reporter, it is a valid option. There will always be a kind of design
> issues without any clearly best solution. It happens that there is a group
> of users supporting solution/fix A whereas solution B which is sometimes a
> true opposite of A has equal number of supporters. If we have already been
> through such discussion in the past and solution A was implemented, changing
> it to B would surely please its fans but next day a new bug would be opened
> as regression from the previous state.
>
>   I don't understand how creation of such a committee would help in this
> case for example. In addition to that quick and clear resolution of bug
> could be perceived as less insulting to some people than leaving the issue
> open for years until it gets invalid.
>
> My two cents,
> -Jirka
>
> Dne 28.9.2011 00:55, Robert Ratcliff napsal(a):
>
>  To save both the developer and the submitter time, it would be nice to
>> just have a bug fix category “Review Required” and the owner assigned to
>> the “Bug Review Board” (in this case the NetBeans Governance Board)
>> rather than the two haggling over what should be done. The feature or
>> bug request may required more review than from a single developer.
>>
>> Closing the bug as ‘WONTFIX” is highly insulting, especially when one
>> has spent a lot of time writing up the enhancement request and it comes
>> down the developer’s personal opinion on what is “good” rather than what
>> is “good” for the user-base at large.
>>
>> *From:*John Ceccarelli [mailto:john.jullion-**[email protected]<[email protected]>
>> ]
>> *Sent:* Tuesday, September 27, 2011 4:24 PM
>> *To:* [email protected]
>> *Cc:* John Yeary
>> *Subject:* [nbdiscuss] 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
>> <john.jullion-ceccarelli@**oracle.com<[email protected]>
>> <mailto:john.jullion-**[email protected]<[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.
>>
>>


-- 
John Yeary
--
http://javaevangelist.blogspot.com
http://www.johnyeary.com
*@jyeary*

"Far better it is to dare mighty things, to win glorious triumphs, even
though checkered by failure, than to take rank with those poor spirits who
neither enjoy much nor suffer much, because they live in the gray twilight
that knows not victory nor defeat."
-- Theodore Roosevelt