Re: Basic questions about the triage process

[Andrew Hyatt <ahyatt@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]


John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>
>> 1) How to identify the bugs to be triaged. I actually don't know the set of
>> bugs you are interested in. All the open ones? Just the ones blocking emacs
>> 25? If I'm using the debbugs package, what's the command I use to display
>> just the set we're interested in?
>
> There are really two sets of bugs we'd like to pay attention to:
>
>   1. Those blocking the release of Emacs 25. Clearly, we can't release until
>      this reaches zero.
>
>   2. All the open bugs, especially the oldest ones. If they don't reproduce
>      against emacs-25 anymore, we'd like to mark them closed as fixed in that
>      release.
>
> #1 is a fairly small list, so just getting more information on those bugs so
> that the developers know how to proceed next is what's important.
>
> #2 is a large list, but would help out the Emacs project by clearing out
> things we don't need to pay attention to anymore.
>
>> Also, what if it does reproduce? I guess just a reply saying that it
>> reproduces? Or does it need to be tagged in some way?
>
> A comment would be valuable, and if what you saw still matches the description
> of the problem.
>
>> Sorry, maybe there was a document that explains this all, and I missed it.
>> If there's isn't such a document, I think it'd be pretty helpful.
>
> Perhaps we do need a targeted document for on-boarding bug herders. If, while
> you're learning this process, you could keep some notes on what helped you to
> get started, Andrew, that could become the start of such a document.

I've put together my notes into a file I stuck in the admin section.
I'm attaching it as a patch.  Feedback would be welcome, of course.  I'm
guessing there's a few other things we'd like to put into this document
as well, but I won't attempt to go beyond just the basic triage
procedure we've discussed in this thread.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-a-file-detailing-how-to-triage-bugs.patch --]
[-- Type: text/x-patch, Size: 3448 bytes --]

From 6ee81d1ac65c49d07c104855b66a1f47a53a4c8f Mon Sep 17 00:00:00 2001
From: Andrew Hyatt <ahyatt@gmail.com>
Date: Tue, 29 Dec 2015 00:36:09 -0500
Subject: [PATCH] Add a file detailing how to triage bugs.

---
 admin/notes/triage | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 admin/notes/triage

diff --git a/admin/notes/triage b/admin/notes/triage
new file mode 100644
index 0000000..f3aa6ad
--- /dev/null
+++ b/admin/notes/triage
@@ -0,0 +1,55 @@
+HOW TO DO 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 the same directory.
+
+* The what and why of bug triage
+
+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.  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.
+
+The process of going through open bugs and acting on them is called
+bug triage.  This document will go through the standard process of
+triaging bugs.
+
+* 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 or debbugs-org), 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.
+     - 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 you can't reproduce, and the bug is older than 2 years old, reply on
+       the thread that you cannot reproduce this on the current release, you
+       will be closing this as unreproducible. Add that if anyone can reproduce
+       it, please re-open the bug. After sending that mail, send a control
+       message on debbugs to set the status to "doneunreproducable".
+     - If you can't reproduce, but the bug is newer than 2 years old, state that
+       you can't reproduce it on the current release, ask if they can try again
+       against the current release. Wait a few weeks for their reply - if they
+       can reproduce it, then that's great, otherwise close as
+       "doneunreproducable".
+  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, you and everyone else can see your changes.
+       
+
+  
-- 
2.4.9 (Apple Git-60)