Archiving the old version of Maintenance of bug reports, because part of what was silently removed yesterday might be useful again when we get more active BugSquad members
--marja 14:14, 23 October 2013 (UTC)
Contents
Ideally, when a bug report is filed:
- it is correct and complete
- a triager immediately assigns it to the right person
- quickly the problem gets fixed and the bug report can be closed.
A bug report can live much longer, could even live for ever
for instance because of one or more of the following reasons:
- nobody reads the report
- the reporter doesn't supply additional information after being asked to
- the reporter did supply that information, but no one is aware he did
- it is an upstream bug
- it was assigned to the wrong person
- the assignee forgets about the bug
- the fixed package is in updates testing, but the assignee forgot to reassign the bug to QA
Of course, we don't want bug reports to live any longer than needed, therefore we maintain them.
Good maintenance of bug reports
means we make sure:
- we start triaging a report within a week after it got filed and make sure the reporter knows we are working on it
- we ping when a reporter doesn't come with requested information within two weeks
- we continue triage within a week after the reporter gave the needed information
- we assign as soon as we are sure the report is complete and valid
- when there is no maintainer, we don't just leave the bug, but cc people who packaged the software before
- after assigning, if the maintainer doesn't set it to the "ASSIGNED" status, we ping him after two weeks to make sure he doesn't forget about the assignment
- when a package without maintainer becomes one, we assign all triaged bugs for that package to him
- we check all bugs that weren't changed in two months, except for the ones that were accepted by the assignee
We don't have enough Bug Squad members, how can we do all this?
We can't. So forget about the idealistic list above
TODO: Make pragmatic list of what we can do
for instance:
- we see to it that bugs with the "NEW" or "REOPENED" status don't become stale bugs
Documentation bugs
Documentation bugs need documentation either to get solved, or until they are solved. For an overview look here
Tools and how to use them
TODO: Expand list of needed Bugzilla searches
NEEDINFO
NEEDINFO bugsquad
To find NEEDINFO assigned to bugsquad bugs that didn't see any action in more than 14 days: NEEDINFObugsquad search
The idea of the NEEDINFObugsquad search is to check whether the requested information was given
- if so:
- if the information is complete: to remove the NEEDINFO keyword
- to ask for additional information if the response wasn't complete
- to assign to the package that is to blame, when possible, if that wasn't already done
- that means to reassign to the correct package, if the wrong package was blamed before
- to assign to the maintainer of the buggy package, when the response was complete
- if the information wasn't given:
- to ping unless there has already been a reminder about the request
- when there was no response after 2 requests over 4 and over 2 weeks ago: close the bug as RESOLVED-OLD and explain (leuhmanu's greasemonkey script makes this easier and can also be useful when pinging after two weeks)
- and of course, forget the above if the reporter of the bug replied that an update fixed the problem and close it as RESOLVED-FIXED, then
NEEDINFO assigned
To find NEEDINFO assigned to anyone but bugsquad bugs that aren't accepted by the assignee (anybody but bugsquad) yet and didn't see any action in more than 14 days: NEEDINFOassigned search
The idea of the NEEDINFOassigned search is to check whether the requested information was given
- if so:
- if the information is complete: to remove the NEEDINFO keyword and to write a comment that you removed that keyword because the information has been received
- to ask for additional information if the response wasn't complete
- to re-assign to the package that is to blame if new information makes clear another package is the culprit
- to re-assign to the maintainer of the real culprit, when needed and possible
- to re-assign to bugsquad when the real culprit hasn't got a maintainer, and to put the committers of that package in the cc of the bug report
- if the information wasn't given:
- to ping unless there has already been a reminder about the request
- when there was no response after 2 requests over 4 and over 2 weeks ago:
- If the assignee has shown interest in the bug: ask him/her whether it should be closed as OLD or not yet
- If the assignee never showed interest: close the bug as OLD and explain (leuhmanu's greasemonkey script makes this easier)
- Forget the above if the reporter of the bug replied that an update fixed the problem and close the report as RESOLVED-FIXED, then
STALE
To find bug reports that didn't see any action since more than three months ago (more than 92days), but excluding:
- enhancement requests
- bugs that have the status ASSIGNED
- bugs that are accepted by the assignee (OK on the whiteboard)
Stale bugs, that aren't assigned or aren't accepted by the assignee, except enhancements
The idea of this search is to make people aware that those bugs tend to be forgotten. At the moment (hope we'll keep it that way) none of those bugs are assigned to bugsquad. For the "assigned to anybody but bugsquad" bugs, a comment needs to be made:
Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED. @ <name of assignee> Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.
Package Requests
Alphabetical order
Package request should have "<package name>, <short description>" in the Summary.
Check against Mandriva 2010.2
package requests that haven't been checked against availability in Mandriva 2010.2
To make upgrading from Mandriva 2010.2 to Mageia 1 easier, all packages that are in Mandriva 2010.2 are allowed to go into Mdv 1. Therefore we put Mdv on the whiteboard when the package was in Mandriva 2010.2, and X when it wasn't
Quick Scripts
Search on your configured media. We can use urpmq --use-distrib to search on other release with mirror. Script is really ugly and needs more improve
#!/bin/bash w3m -T text/html -dump "https://bugs.mageia.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=cf_rpmpkg&component=New%20RPM%20package%20request&product=Mageia&query_format=advanced&ctype=csv"| sed s/\"//g| sed -e "s/^\(.*\)-[^-]*-[^-]*$/\1/"| (while read pkg do a=`echo $pkg |cut -d, -f1` pk=`echo $pkg |cut -d, -f2` if [ -z $pk ] then pk=`echo Nothing!` echo -e "$a: $pk\n~~~" else b=$(echo $pkg |urpmq $pk -ya --force) echo -e "$a: $b for $pk\n~~~" fi done)
End of life (EOL) Release
take from fedora https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Bugzilla_Product_Description--Fedora_16_EOL
This message will be send 1 months before the official EOF:
This message is a reminder that Mageia 1 is nearing its end of life. Approximately 30 (thirty) days from now Mageia will stop maintaining and issuing updates for Mageia 1. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '1'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 1's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 1 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.
This message will be send the day or a little after the day of the EOL:
Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia. And reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Question: should we add another Status like EOF ?
Mga1 stats
- 05/11/12: Messages sent to 314 bugs (without 2bugs where the qa was assigned, and after some cleaning) after the blog post
- Before the first reminder: in table
critical major normal minor enhancement Total . 2 9 2 1 14 FIXED 35 57 582 28 81 783 INVALID 8 18 68 8 13 115 WONTFIX 1 8 51 10 21 91 DUPLICATE 3 15 73 4 18 113 WORKSFORME 1 7 24 1 2 35 OLD 11 16 49 7 17 100 Total 59 123 856 60 153 1251
- Before the real closing: in table
critical major normal minor enhancement Total . 2 9 2 1 14 FIXED 35 58 587 29 83 792 INVALID 8 18 68 8 13 115 WONTFIX 1 8 53 10 22 94 DUPLICATE 3 15 74 4 18 114 WORKSFORME 1 8 27 1 2 39 OLD 11 17 55 7 19 109 Total 59 126 873 61 158 1277