>From 3e496267725a6a44e32439fe8934ebda5a33f150 Mon Sep 17 00:00:00 2001 From: Andrew Hyatt Date: Tue, 29 Dec 2015 00:36:09 -0500 Subject: [PATCH] Add a file detailing how to triage bugs. Further changes in reponse to Eli's mail. --- CONTRIBUTE | 9 +++++++++ admin/notes/triage | 44 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 53 insertions(+) create mode 100644 admin/notes/triage diff --git a/CONTRIBUTE b/CONTRIBUTE index b385d68..6983df5 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -222,6 +222,15 @@ the tracker with the corresponding bugs/issues. GNU ELPA has a 'debbugs' package that allows accessing the tracker database from Emacs. +A large backlog of bugs is disheartening to the developers, and a +culture of ignoring bugs is harmful to users, who expect software that +works. Bugs have to be regularly looked at and acted upon. Not all +bugs are critical, but at the least, each bug needs to be regularly +re-reviewed to make sure it is still reproducible. + +The process of going through open bugs and acting on them is called +bug triage. This process is described in the file admin/notes/triage. + ** Document your changes. Any change that matters to end-users should have an entry in etc/NEWS. diff --git a/admin/notes/triage b/admin/notes/triage new file mode 100644 index 0000000..a2518ca --- /dev/null +++ b/admin/notes/triage @@ -0,0 +1,44 @@ +HOW TO TRIAGE EMACS BUGS -*- outline -*- + +This document just describes the procedure of triaging bugs, for +information on how to work with the bug tracker, see the bugtracker +file in this same directory. + +* Bug backlog triage procedure + +The goal of this triage is to prune down the list of old bugs, closing +the ones that are not reproducible on the current release. + + 1. To start, enter debbugs mode (either debbugs-gnu, debbugs-org, or via the + web browser), and accept the default list option of bugs that have severity + serious, important, or normal. + 2. This will also show closed bugs that have yet to be archived. You can + filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress). + 3. For each bug, do the following: + - Read the mail thread for the bug. Find out if anyone has been able to + reproduce this on the current release. + - If someone has been able to, then your work is finished for this bug. + - Make sure there's enough information to reproduce the bug. It should be + very clear how to reproduce. If not, please ask for specific steps to + reproduce. If you don't get them, and you can't reproduce without them, + you can close as "doneunreproducible". + - If no one has mentioned being able to reproduce on the current release, + read the bug description and attempt to reproduce on an emacs started + with "emacs -Q" (the goal is to not let our personal configs interfere + with bug testing). + - If you can reproduce, then reply on the thread (either on the original + message, or anywhere you find appropriate) that you can reproduce this on + the current release. If your reproduction gives additional info (such as + a backtrace), then add that as well, since it will help whoever attempts + to fix it. + - If you can't reproduce, state that you can't reproduce it on the current + release, ask if they can try again against the current release. Tag the + bug as "unreproducable". Wait a few weeks for their reply - if they can + reproduce it, then that's great, otherwise close as "doneunreproducible". + 4. Your changes will take some time to take effect. After a period of minutes + to hours, you will get a mail telling you the control message has been + processed. At this point, if there were no errors detected, you and + everyone else can see your changes. + + + -- 2.4.9 (Apple Git-60)