From: Andrew Hyatt Date: Sat, 9 Jan 2016 04:04:59 +0000 (-0500) Subject: Rename the notes/admin/triage file to bug-triage. X-Git-Tag: emacs-26.0.90~2819^2~22 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=33715e54e3aa9d056ddc207d052e0f260aa9f6a7;p=emacs.git Rename the notes/admin/triage file to bug-triage. * CONTRIBUTE: Change reference to the triage file name. * admin/notes/triage: Rename file to admin/notes/bug-triage. --- diff --git a/CONTRIBUTE b/CONTRIBUTE index 177a38cffd6..19ec68221c4 100644 --- a/CONTRIBUTE +++ b/CONTRIBUTE @@ -233,7 +233,7 @@ is still reproducible. The process of going through old or new bugs and acting on them is called bug triage. This process is described in the file -admin/notes/triage. +admin/notes/bug-triage. ** Document your changes. diff --git a/admin/notes/bug-triage b/admin/notes/bug-triage new file mode 100644 index 00000000000..5b0e35c144c --- /dev/null +++ b/admin/notes/bug-triage @@ -0,0 +1,68 @@ +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 +for the basics. You can also install the debbugs ELPA package for access to M-x +debbugs-gnu, an emacs interface to debbugs, and M-x debbugs-org, an emacs +interface via org-mode. + +* 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". + - If the bug ends up still open, make sure the priority and other tags + seems reasonable. + 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. If there are errors, read the error + text - if you need help, consulting the bugtracker documentation in this + same directory. + +* New bug triage process + +The goal of the new bug triage process is similar to the backlog triage process, +except that the focus is on prioritizing the bug, and making sure it is has +necessary information for others to act on. + +For each new bug, ask the following questions: + + 1. Is the bug report written in a way to be easy to reproduce (starts from + emacs -Q, etc.)? If not, ask the reporter to try and reproduce it on an + emacs without customization. + 2. Is the bug report written against the latest emacs? If not, try to + reproduce on the latest version, and if it can't be reproduced, ask the + reporter to try again with the latest version. + 3. Is the bug the same as another bug? If so, merge the bugs. + 4. What is the priority of the bug? Add a priority: critical, grave, serious, + important, normal, minor, or wishlist. + 5. Who should be the owner? This depends on what component the bug is part + of. You can look at the admin/MAINTAINERS file (then you can just search + emacs-devel to match the name with an email address). diff --git a/admin/notes/triage b/admin/notes/triage deleted file mode 100644 index 5b0e35c144c..00000000000 --- a/admin/notes/triage +++ /dev/null @@ -1,68 +0,0 @@ -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 -for the basics. You can also install the debbugs ELPA package for access to M-x -debbugs-gnu, an emacs interface to debbugs, and M-x debbugs-org, an emacs -interface via org-mode. - -* 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". - - If the bug ends up still open, make sure the priority and other tags - seems reasonable. - 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. If there are errors, read the error - text - if you need help, consulting the bugtracker documentation in this - same directory. - -* New bug triage process - -The goal of the new bug triage process is similar to the backlog triage process, -except that the focus is on prioritizing the bug, and making sure it is has -necessary information for others to act on. - -For each new bug, ask the following questions: - - 1. Is the bug report written in a way to be easy to reproduce (starts from - emacs -Q, etc.)? If not, ask the reporter to try and reproduce it on an - emacs without customization. - 2. Is the bug report written against the latest emacs? If not, try to - reproduce on the latest version, and if it can't be reproduced, ask the - reporter to try again with the latest version. - 3. Is the bug the same as another bug? If so, merge the bugs. - 4. What is the priority of the bug? Add a priority: critical, grave, serious, - important, normal, minor, or wishlist. - 5. Who should be the owner? This depends on what component the bug is part - of. You can look at the admin/MAINTAINERS file (then you can just search - emacs-devel to match the name with an email address).