ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] fuzz failures not generating bugs

From: Evan Huus <eapache@xxxxxxxxx>
Date: Fri, 30 Nov 2012 16:54:25 -0500
On Fri, Nov 30, 2012 at 4:34 PM, Bill Meier <wmeier@xxxxxxxxxxx> wrote:
On 11/30/2012 4:08 PM, Evan Huus wrote:
    Would UNCONFIRMED be less confusing than CONFIRMED?


I would think so. It's bothered me for a while that we didn't have a way
to distinguish between "brand new, nobody has looked at it yet" bugs and
"solution identified, but nobody wants to work on it" bugs. Separating
our current NEW bugs into either UNCONFIRMED or CONFIRMED states seems
like the right way to do that.


+1

I would also note that presumably the status can just go from UNCONFIRMED to RESOLVED if a bug is just immediately fixed upon reviewing.
 
I would hope so.


While on the topic, I'd also love an "INCOMPLETE" state like Launchpad
(for bugs that are waiting on the submitter for more information -- we
seem to have a fair number of those), but I suppose one thing at a time :)


+1, I think.

How does the incomplete status get updated when the additional information is provided ? manually ?

If manually, is this OK in practice or do peole forget to update the status ?

The submitter sets it back to NEW (or UNCONFIRMED) manually when they provide the requested information. People don't forget, because bugs in this state expire after 60 days otherwise. It's a great method for keeping the bug list short :)