NorduGrid uses a Bugzilla service for bug report and request tracking. Software is sub-divided logically into components, each of which has a responsible person («owner»), assigned by the technical coordination group. Reporters are asked to specify the relevant component, such that Bugzilla automatically assigns new reports to the respective owners. The following procedures and policies are designed to ensure speedy and quality processing of the requests.
A bug's life cycle goes through the following states: NEW, ASISGNED, RESOLVED (with several resolution options), VERIFIED and CLOSED. Fixed bugs (in states RESOLVED, VERIFIED or CLOSED) can be resurrected and get into the state REOPENED. Newly reported bugs are automatically assigned NEW state.
NEW bugs should be acted upon within 2 working days. Possible actions are:
Reminders will be sent to the prospective bug owners by Bugzilla automatically. Every week the technical coordination group will check whether there are unattended NEW bugs and decide what action is to be taken (re-assign, close, contact the owner etc). In case a bug is re-assigned from any state, it acquires NEW status again, and from this moment the new 2 days deadline applies.
Bugs are placed into ASSIGNED state automatically when the owner "accepts" the report. "Accept" action indicates that the owner accepts the report as valid or agrees to check it. If the owner believes the report belongs to someone else, he/she must re-assign it within the same limit of 2 days.
There is no general limit on how long the bugs can remain in the ASSIGNED state.
High severity bugs (Blocker and Critical) are expected to be acted upon immediately.
If a person accumulates unreasonably high amount of assigned bugs, or otherwise has no possibility to take care of the assigned bugs, an effort must be made to re-assign the bugs. This effort should be primarily undertaken by the bug owner him/herself, optionally with the help from the technical coordination group. Re-assigning stalled bugs is strongly encouraged.
Everybody who believes the bug is resolved can trigger this state via Bugzilla interface. Resolution can be of several kinds: FIXED, INVALID, WONTFIX, LATER, REMIND, WORKSFORME. Meanings of the terms are self-explanatory, and are also described in details in Bugzilla.
Whoever claims the bug is resolved must elaborate on resolution in the "Additional comments" box. The common practice for the FIXED resolution is to write "Fixed in SVN, expected to be available in tag NNN". If the bug is resolved with any other resolution, it must be commented as well (e.g., explain why it is invalid or why it won't be fixed, or how much later it will be fixed etc).
Every resolution must be verified. This can be done by any independent person (not the bug owner) who has an evidence that the resolution is adequate.
If the bug is declared FIXED, the original reporter is expected to check whether the problem is indeed solved, at the first opportunity.
Any other person can provide an evidence and mark the bug VERIFIED as well, in which case the evidence must be reported in the "Additional comments" field.
Other resolutions (INVALID, WONTFIX etc) must be verified by the technical coordination group.
If the resolution is WONTFIX, the technical coordination group may decide to re-assign the bug.
The bug is declared closed by the technical coordination group. This happens in the following cases:
The technical coordination group will inspect and close VERIFIED bugs once a month.
Bugs in states RESOLVED, VERIFIED or CLOSED can be REOPENED by anybody who believes the problem is not gone. The bug life cycle then restarts from the NEW state. REOPENED state is completely equivalent to NEW, implying the same 2 days deadline.
Quality assurance for bugs reported to all ARC versions is done by the technical coordination group during the regular meetings.
Every weekly meeting has a standing agenda item "New bugs" dedicated to identifying unattended bugs and decide on actions to be taken.
Once a month, the entire meeting is dedicated to bug management. The procedure outline is such:
The technical coordination group may decide to invite an external expert to discuss specific outstanding bugs.
Monthly summary reports on bug status are circulated by the technical coordination group to the nordugrid-discuss mailing list.