So, as of just a few minutes ago, the trunk Bugzilla code has a new default status workflow that looks like this:
- UNCONFIRMED
- CONFIRMED
- IN_PROGRESS
- RESOLVED
- 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
The Bugzilla Update 
This is a brilliant improvement.
Will the bugzilla.mozilla.org website be using this, when version 4 is released?
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
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
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!
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
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.
That’s fine! đŸ™‚ Some people do use that resolution. We found that most installations do not, but some do, so you are totally welcome to keep it. đŸ™‚
-Max
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.
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.”
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*<
Sounds less technical to me, which makes it more useful for less technical projects, and projects that aren’t necessarily based on code.
Oh, you know, I didn’t even think about that, but it’s pretty much true!
-Max
Hw was the bugzilla 4.0.2 can anyone rply
We are using bugzilla 3.0 version and we need to upgrade the new version please suggest me which version is good
The official answer will always be “the current stable version”. They all know how to upgrade themselves from older versions, just follow the upgrade instructions in the ReadMe.
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.
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.
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