Re: New bug handling policy ?

John Ceccarelli <[email protected]> Tue, 20 Nov 2012 10:41:57 -0800
Newsgroups gmane.comp.java.netbeans.general
Organization Oracle Corporation
Message-ID <[email protected]>
Hi folks,

What happens is that bugs accumulate during the feature development 
phase of a release, then during stabilization the engineers go through 
the backlog of issues and evaluate. And yes they are under tremendous 
pressure to reach our quality thresholds so this can sometimes result in 
what seems like harsh responses from the devs.

You have to understand there is no "sustaining" department at Oracle. 
There is no team whose explicit job it is to evaluate bugs as they come 
in and only pass the valid, actionable bugs to the engineers. So please 
be patient with us as we try to manage the large task of implementing 
compelling new features along with responding to the mountains of user 
feedback in the bug tracking system and on the mailing lists.

Emilian is correct, however. If a bug is incomplete or cannot be 
reproduced, it will be closed as Incomplete or Invalid. Simply reopen it 
with more details if this happens to you. But please, if the developer 
decides that the bug is one we will not fix or that the current behavior 
is as designed, don't just reopen the bug repeatedly. This doesn't help 
anyone.

Thanks again,

-J


On 11/19/2012 4:04 AM, Emilian Bold wrote:
> I don't think this policy is very new. I've generally noticed that right before a major release people are eager to get rid of bugs. Maybe under Oracle developers are also evaluated with these metrics (number of open-bugs, etc) but I have no concrete information about this.
>
> Harshness is also a matter of the person you are interacting with (and your own state of mind). For example, one might say David's reply was also a bit harsh although informative.
>
> In my years of reporting bugs on NetBeans I've seen two things that annoy me to no end and they are not particularly new: leaving bugs untouched for a very long time and closing bugs as "works for me" when it's only been "fixed" in a nightly build.
>
> That being said, closing an incomplete issue isn't a problem: you can always re-open the issue with more information.
>
> As for moving to another category, that is something that I would expect to be done by the developers, if possible, especially given the fact that not all issue reporters know the internal design. One can also use the generic 'ide' category.
>
> I guess examples could help to see what went wrong for your issues.
>
> --emi
>
> On Nov 12, 2012, at 6:08 PM, David Strupl wrote:
>
>> Hello,
>>
>> the bug lifecycle is described here:
>>
>> http://wiki.netbeans.org/IssueLifeCycle
>>
>> Hope it helps explain at least a bit ...
>>
>> Br,
>>
>> David
>>
>> On 11/12/12 4:46 PM, [email protected] wrote:
>>> I'm starting to wonder - is there a new policy or a metric on how bugs
>>> are handled in bugzilla ? It seems that there is this eagerness from
>>> the developers to close the issues as soon as they're created - even if
>>> the issue is not confirmed, needs more information, etc. The other
>>> aspect that's somewhat bothersome is developers closing an issue and
>>> telling users that a new issue needs to be filed elsewhere to be looked
>>> at - if it's obvious that something is an issue in the wrong category,
>>> shouldn't the developer (who is familiar w/ the process of the issue
>>> transitions and where the issue should really be) be the person who
>>> creates the new issue, instead of closing the existing one and hoping
>>> that a new issue wouldn't be created in the "proper" category ?
>>>
>>> I appreciate the quick response on issues - it's great to see that
>>> someone is looking at issues soon after they're opened.  At the same
>>> time, it feels a bit harsh when an issue I create is immediately
>>> closed, even if it needs more information .
>>>
>>> Maybe I don't understand the states of issues in the netbeans bugzilla
>>> and it's not a big deal when my issue is closed (e.g. when more
>>> information is needed).  This seems like a recent development, but I
>>> might be wrong.