Bug Database Changes Completed - PLEASE READ!
Mark Chia
mark at runrev.com
Sun Feb 8 13:37:14 EST 2004
Hello Revolutionaries!
The changes to the Bugzilla have been completed and tested. It is
important for everyone to read what has changed and to get an
understanding of how this impacts on the management of bugs. Therefore,
please read this message in its entirety.
************** IMPORTANT: PLEASE READ **************
Bugzilla sends email to people when the Resolution of a bug has changed.
Since we have made changes to the terms used in some of the Resolutions
(such as "INVALID" is now "NOT_A_BUG"), Bugzilla will automatically send
out emails to people informing them of the change of Resolution, even if
the bug has *already been resolved*. For example, if a person had a bug
from a long time ago that got resolved as "INVALID", that person will
receive an email on that bug letting them know the Resolution was
changed to "NOT_A_BUG". So please be prepared for getting emails from
Bugzilla on these initial Resolution changes, which you can ignore or
delete.
****************************************************
Here are the changes that have been made:
Statuses
--------
PENDING has been added to the list of Statuses, and is used to
distinguish between bugs that have been submitted, but not yet
reviewed (UNCONFIRMED) and those that have been reviewed, but
cannot be assigned yet due to lack of information, a reproducible
recipe, etc. (PENDING).
PENDING inserts itself into the workflow between UNCONFIRMED and
NEW. For those of you who may be unfamiliar with the workflow on
the bugs, or would like to refresh your memory, look at the
bottom of this email for a walkthrough on the bug process.
Statuses now in the system:
UNCONFIRMED
PENDING
NEW
ASSIGNED
REOPENED
RESOLVED
VERIFIED
CLOSED
Resolutions
-----------
- The Resolutions of REMIND and LATER have been removed (for more info
on
LATER, see "Target Milestones", below).
- INVALID is now NOT_A_BUG
- WONTFIX is now ISNT_FIXABLE
- WORKSFORME is now CANT_REPRODUCE
- MOVED has been kept for future use.
Resolutions now in the system:
FIXED
NOT_A_BUG
ISNT_FIXABLE
DUPLICATE
CANT_REPRODUCE
MOVED
--- (not resolved)
Target Milestones
-----------------
Starting now, we will be using the Target Milestones to indicate in what
version a particular bug was resolved. So any bugs that we are fixing
for 2.2 will get the Target of "2.2". Bugs that were previously marked
with a status of LATER (indicating that we want to fix it, but just not
in the current build) have been changed to a status of ASSIGNED, with a
resolution of --- and a Target Milestone of "Future". This will allow us
to quickly find the bugs that we could not address in the current
development cycle. Once we address them, we will change the Target
Milestone to the version number in which it was resolved (and of course
set a resolution).
************** IMPORTANT: PLEASE READ **************
Please note that this is currently an option menu, and *can*
be changed by people who edit their own bugs. WE STRONGLY URGE YOU TO
LEAVE THIS OPTION MENU ALONE (for obvious reasons). We want to have a
consistent way of being able to identify when bugs have been fixed, and
this looks like the best way to do this.
****************************************************
Help Files
----------
We have also modified the help files that discuss the Statuses,
Resolutions and Target Milestones so that if you need to look at the
help, it will correspond to the actual system yoou're using. If you
happen to find a place that we might have missed, please let us know and
we will get those fixed.
Bug Workflow
------------
Here's the workflow for the new system:
1) User submits a bug. Bugzilla automatically sets the status to
UNCONFIRMED, and the resolution to "---".
2) QA person looks at the bug.
2a) If it is just looked at but not responded to in any way, the
status is left as UNCONFIRMED.
2b) If more information is needed, a comment is added to the bug
and the status is changed to PENDING.
2c) If there's enough information, an attempt to reproduce the
bug is made.
2c-i) If it can be reproduced, the status is changed to NEW
and it is assigned to someone to fix.
2c-ii) If it cannot be reproduced, a comment is added to the
bug to ask the original submitter if they can come
up with another recipe (since we couldn't reproduce
it) and the status remains PENDING. If we ever *can*
reproduce it, we act as (2c-i) above. If we can
*never* reproduce it, we change the status to
RESOLVED and the resolution to CANT_REPRODUCE. The
Target Milestone is then set to the targetted
release version.
2d) If it is a misunderstanding by the user and the bug is really
not a bug, the status is set to RESOLVED, and the resolution
is set to NOT_A_BUG. The Target Milestone is then set to
the targetted release version.
2e) If the bug is recognized and determined to be a duplicate of
an existing bug, a comment is entered pointing to the
duplicate, the status is set to RESOLVED, and the resolution
is set to DUPLICATE. The Target Milestone is then set to
the targetted release version.
3) Bugs marked NEW are reviewed by the person to whom they were
assigned. If the assignee feels that they are the right person to
fix the bug, they change the status of the bug to ASSIGNED. If
the assignee feels they are *not* the right person to fix the
bug, the status is left as NEW, but the bug is reassigned to
someone else, and the new assignee does the same review.
4) Bugs marked ASSIGNED are then worked on by the assignee.
4a) If the assignee feels more information is needed, the bug
is left as ASSIGNED, but a comment is added to the bug
(which will be sent back to the submitter for more info
automatically).
4b) If the assignee can't fix the bug (because it's unable to be
fixed (for example, an OS issue), the status is changed to
RESOLVED, and the resolution is set to ISNT_FIXABLE. The
Target Milestone is then set to the targetted release
version.
4c) If the assignee fixes the bug, the status is changed to
RESOLVED, and the resolution is set to FIXED. The Target
Milestone is then set to the targetted release version.
4d) If the assignee determines that the bug submitted is really
not a bug (and the QA person thought that it *was*), a comment
is added and the status is set to RESOLVED and the resolution
is set to NOT_A_BUG. The Target Milestone is then set to the
targetted release version.
4e) If the assignee determines that the bug submitted is a
duplicate of an existing bug (and the QA person didn't catch
it), a comment is entered pointing to the duplicate, the
status is set to RESOLVED, and the resolution is set to
DUPLICATE. The Target Milestone is then set to the targetted
release version.
5) When a new interim build is released to the RunRev development
team, the QA person will check the RESOLVED bugs against the new
build. If a bug is actually fixed, the status is set to CLOSED.
Ken Ray is new Bugzilla Maintainer
----------------------------------
Ken has graciously agreed to help us with managing the bugs in Bugzilla,
and will be acting for a while as our QA person for the new system. As
you may already know, Ken developed RevZilla, the excellent Revolution
front-end to Bugzilla, so he is uniquely aware of some of the structure
and challenges in the Bugzilla system, and was fundamental in getting
the
above changes to the Bugzilla system designed and implemented. So don't
be surprised if you see him responding to bugs!
Now that we have a revised system where bugs can be more appropriately
categorized and dealt with, as well as someone to help manage the bugs,
you should start seeing more movement on the bugs you have already
submitted. We apologize for the slow response we've had to bugs in the
past, and are redoubling our efforts to make sure that bugs are
responded to and fixed as quickly as possible.
If you have any questions related to the changes or Bugzilla itself,
please send them to Ken (ken at runrev.com) and CC me (mark at
runrev.com).
Thanks for your patience in reading this long email, and enjoy the new
changes!
Mark
--
Mark Chia ~ http://www.runrev.com/
Runtime Revolution - User-Centric Development Tools
More information about the use-livecode
mailing list