Bugzilla 4.0 Has a New Default Status Workflow

So, as of just a few minutes ago, the trunk Bugzilla code has a new default status workflow that looks like this:

  1. UNCONFIRMED
  2. CONFIRMED
  3. IN_PROGRESS
  4. RESOLVED
  5. VERIFIED

If you upgrade your installation to 4.0 (when it comes out), you will, by default, keep the old workflow, whatever it was. This is okay, except that there are now certain parts of Bugzilla (like, various pieces of text and so on) that assume you are using the new workflow, and we think the new workflow is much nicer, simpler, and clearer. So we’ve also included a script that will convert the old default workflow into the new default workflow, called contrib/convert-workflow.pl. We recommend that everybody convert to the new workflow, if you can.

If you want to see the new workflow in action, check out the bugzilla-tip demo installation.

Why Is There No NEW Status?

You might be asking yourself–why is there no “NEW” status in this new workflow? Well, we think that the status workflow should tell you something about the bug that the other fields don’t tell you about the bug. In particular, you can tell if a bug is new by looking at when the bug was filed, how many comments there are, who the assignee is, etc. In fact, in the past, a bug that had the “NEW” status may not have in fact actually been NEW–it was just not being worked on.

We feel that CONFIRMED and UNCONFIRMED both actually describe something more helpful about the bug and are more accurate than NEW.

-Max

About these ads

18 Responses to “Bugzilla 4.0 Has a New Default Status Workflow”


  1. 1 Josh July 6, 2010 at 8:09 am

    This is a brilliant improvement.

    Will the bugzilla.mozilla.org website be using this, when version 4 is released?

    • 2 Max Kanat-Alexander July 6, 2010 at 3:25 pm

      Thanks! Yes, I hope that bugzilla.mozilla.org will be using the improvement. It came originally out of a discussion that Mozilla had, so I hope that they will choose to change to the workflow when they upgrade.

      -Max

  2. 3 AndersH July 6, 2010 at 9:06 am

    If anybody else is wondering what changed from the old way, this is the description from the conversion script:

    This will convert the status of all bugs using the following system:
    “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)
    This change will be immediate. The history of each bug will also be changed so that it appears that these statuses were always in existence.
    Emails will not be sent for the change.

    http://bzr.mozilla.org/bugzilla/trunk/annotate/head:/contrib/convert-workflow.pl

    • 4 Tsila August 16, 2010 at 1:09 pm

      I am wondering, which development method or concept is behind it?
      Starting from the beginning: “Confirmed” hm…maybe I am not perfect in linguistic but it is a strange starting status for me.
      Next one: losing “REOPEN” status is a pain for me as well as losing “Closed” status in quality point of view – it looks like Bugzilla does not take the feedback loops seriously. As it is in my mind: QA should verify the solution (verification)is it working or not, then the customer(user) who opened the ticket, who initiated the change request has the right to accept the resolution if that is suitable for the problem in fact (validation).
      Will be the next step to eliminate QA contact from the workflow after eliminating the customer(user) from it? Or I am totally on the wrong side? Please help to catch the logic behind it!

      • 5 Max Kanat-Alexander August 16, 2010 at 10:13 pm

        There’s no “development method” behind it. We don’t subscribe to any particular development model, and we certainly don’t try to force people into one.

        These are just the common things that most people actually need, in our experience.

        You can still customize the workflow, this is just the default.

        -Max

      • 6 disey September 14, 2010 at 10:03 pm

        I agree 100% with Tsila! When devers mark bug as Resolved, they build and compile program. Code gets it’s first test and is marked Verified by the QA dept. We may have several interim builds during our log and resolve process. We also use the REOPENED status as a trigger for which bugs have been tested and failed, but need to be addressed in the current cycle. Then when devers build the final release – each ‘bug’ is restested and marked as Closed. This also triggers the announcement to the clients, that their logged issues have been addressed and are included in this release. I don’t think we’ll be converting the past 9 years of bugs from Closed to Verified.

    • 8 gayle noble July 8, 2013 at 3:06 pm

      closed is a nice option when what appeared to be a bug turns out not to be a bug. Verified has no meaning in this case. A bug written against the hardware turns out to be a totally different problem in software “resolved, and or verified are meaningless. CLOSED makes sense. If you don’t like something, you don’t have to use it. However, there are those of us that are doing things you never thought of and CLOSED works real nice in many of these cases. Kindly reconsider making bugzilla only suitable for you.

      • 9 Dave Miller July 9, 2013 at 5:50 am

        Note that although CLOSED was removed as a default option, it will remain if you already had it, and the new system is extensible so if you have a new install and you want it, you can easily add it back yourself. This is hardly “only suitable for me.”

        • 10 gayle noble July 9, 2013 at 8:51 pm

          Cool! I’ll try and edit it. I am, however, a certified California Air Head, born in Hollywood Hospital, so I hope the documentation is real clear >*grin*<

  3. 11 Havvy July 7, 2010 at 5:00 am

    Sounds less technical to me, which makes it more useful for less technical projects, and projects that aren’t necessarily based on code.

  4. 13 Suresh Raju November 14, 2011 at 12:20 pm

    Hw was the bugzilla 4.0.2 can anyone rply

  5. 16 Dan Perry February 1, 2012 at 11:15 am

    Max, what great improvements you have made. As new bugs are entered (with our current configured system) the come up with “confirmed” status and I cant find where default.bug_status is set.

  6. 17 evoisard February 23, 2012 at 2:01 am

    mmh, I like the new naming, though CLOSED is missing to fit to our dev workflow. And REOPENED is useful for extracting statistics about bugs resolutions and regressions. Good thing we still can add them.

  7. 18 Shams April 23, 2013 at 9:13 am

    I’ve upgrade our Bugzilla to version 4.2.5 yesterday and ran the convert-workflow.pl. Now I have the UNCONFIRMED status enabled in all product but the Value ‘UNCONFIRMED’ for the ‘Status’ (bug_status) field is disabled and can’t be enabled (can not activate the checkbox). The result is that I can’t file a Bug in Status UNCONFIRMED. It starts with CONFIRMED although in editworkflow.cgi the {start} row has UNCONFIRMED, CONFIRMED and IN_PROGRESS all checked (activated).

    Any idea what I’ve done worge or how I can start bugs in UNCONFIRMED status?

    many thanx in advance
    shams


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Upcoming Events

  • Bugzilla Public Meeting September 24, 2014 at 7:00 am – 8:00 am Mozilla Vidyo, Air Mozilla, IRC Public Bugzilla planning meeting. Anyone interested in contrib uting to Bugzilla, in planning, development, testing, documentation, o r any other aspect, should feel free to attend. See https://wiki.mozill a.org/Bugzilla:Meetings for more.
  • Bugzilla Public Meeting October 22, 2014 at 2:00 pm – 3:00 pm Mozilla Vidyo, Air Mozilla, IRC Public Bugzilla planning meeting. Anyone interested in contrib uting to Bugzilla, in planning, development, testing, documentation, o r any other aspect, should feel free to attend. See https://wiki.mozill a.org/Bugzilla:Meetings for more.

Follow

Get every new post delivered to your Inbox.

Join 556 other followers

%d bloggers like this: