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

From: Bill Meier <wmeier@xxxxxxxxxxx>
Date: Fri, 30 Nov 2012 15:01:47 -0500
On 11/30/2012 2:05 PM, Gerald Combs wrote:

It looks like I should have read the release notes more closely. Fuzz
failure reporting uses the bugzilla-submit script, which requires
converting to a new status workflow in Bugzilla 4.0 and 4.2:

http://www.bugzilla.org/releases/4.2/release-notes.html#v40_feat_workflow

Converting would mean going from this:

   http://www.bugzilla.org/docs/3.6/en/html/lifecycle.html

to this:

   http://www.bugzilla.org/docs/4.2/en/html/lifecycle.html

Unless anyone really prefers the old, more complex workflow I'll
schedule the conversion for tomorrow morning PST.

Assuming that the conversion script mentioned in

https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/

will be run, it appears that the changes in the current status values will be as follows:

�NEW� will become �CONFIRMED�
�ASSIGNED� will become �IN_PROGRESS�
�REOPENED� will become �CONFIRMED� (and the �REOPENED� status will be removed)
�CLOSED� will become �VERIFIED� (and the �CLOSED� status will be removed)


Also, I'm guessing that, after the update, the initial status of a bug will now be "CONFIRMED" (which corresponds with our current initial status of "New").

Or: will we now start with "UNCONFIRMED" ?


(Quick first comments):

I appreciate that opening a discusion about "lifecycle" & etc is not the most important thing to do in life, so my general reaction is to say that the new workflow will be fine as long as we have a (short) paragraph someplace saying what the workflow is and how we'll use it.

That being said, I can imagine that starting with "Confirmed" might cause some puzzlement from those used to seeing "NEW" as the initial status.


Bill