From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andrew Hyatt Newsgroups: gmane.emacs.devel Subject: Re: Basic questions about the triage process Date: Tue, 29 Dec 2015 00:40:08 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1451367639 29633 80.91.229.3 (29 Dec 2015 05:40:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2015 05:40:39 +0000 (UTC) To: "emacs-devel\@gnu.org" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 06:40:34 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aDn1M-0007QS-9n for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 06:40:32 +0100 Original-Received: from localhost ([::1]:47157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDn1L-0000VR-Cv for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 00:40:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54237) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDn16-0000V6-VR for emacs-devel@gnu.org; Tue, 29 Dec 2015 00:40:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDn11-0004tA-VG for emacs-devel@gnu.org; Tue, 29 Dec 2015 00:40:16 -0500 Original-Received: from mail-qg0-x231.google.com ([2607:f8b0:400d:c04::231]:36569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDn11-0004t6-Q5 for emacs-devel@gnu.org; Tue, 29 Dec 2015 00:40:11 -0500 Original-Received: by mail-qg0-x231.google.com with SMTP id e32so68394973qgf.3 for ; Mon, 28 Dec 2015 21:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=PYl5aHpUfDwCtMXCUCt29d7jFrXzSxvom/HmrbCdJmk=; b=jiHE1j2PH5GsMsQOC3ZIcVlsgRwA+evDXjsVo+Qjt4/NvB0H7a9ABJ+VBpy6JwwZiv Q6+bTU+1NgMtQOmk1WMC02VaRc/drovTLbSMk29fBZqU+oEH4EzdL3CSBhNdsRhcBlFG YPVGotDtWAEeqPwGP3susb33xpUd883WIluvf/3pMoGzB2YKN8CXzKDoVohEbGpc6stn A6JEzjYksClZPENeVI8VqQ5LRKlNhzFMaccTmnhzs/lx/tggWVRr3RycwADaPgoIMDlX DDGMT6LdywqJ7mH3NzE0pUC9QgBXrsd3JyoPe2cQjLnHTuOD818k55QXfE95oHtiOEIH P/zQ== X-Received: by 10.140.44.38 with SMTP id f35mr2840096qga.49.1451367611093; Mon, 28 Dec 2015 21:40:11 -0800 (PST) Original-Received: from Andrews-MacBook-Pro.local.ahyatt-laptop (cpe-74-73-128-199.nyc.res.rr.com. [74.73.128.199]) by smtp.gmail.com with ESMTPSA id x76sm28444009qhb.48.2015.12.28.21.40.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Dec 2015 21:40:09 -0800 (PST) In-Reply-To: (John Wiegley's message of "Mon, 28 Dec 2015 12:24:55 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c04::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:197062 Archived-At: --=-=-= Content-Type: text/plain John Wiegley writes: >>>>>> Andrew Hyatt 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. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Add-a-file-detailing-how-to-triage-bugs.patch >From 6ee81d1ac65c49d07c104855b66a1f47a53a4c8f 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. --- 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) --=-=-=--