From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Basic questions about the triage process Date: Tue, 29 Dec 2015 19:12:25 +0200 Message-ID: <83ege5dvra.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1451409115 29265 80.91.229.3 (29 Dec 2015 17:11:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Dec 2015 17:11:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andrew Hyatt Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 29 18:11:50 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 1aDxoK-00070b-Hf for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 18:11:48 +0100 Original-Received: from localhost ([::1]:49441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDxoJ-0003j5-QL for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 12:11:47 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44576) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDxo7-0003io-4a for emacs-devel@gnu.org; Tue, 29 Dec 2015 12:11:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aDxo3-0005VF-Uv for emacs-devel@gnu.org; Tue, 29 Dec 2015 12:11:35 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aDxo3-0005VB-RQ; Tue, 29 Dec 2015 12:11:31 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4546 helo=HOME-C4E4A596F7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aDxo3-0000MV-8f; Tue, 29 Dec 2015 12:11:31 -0500 In-reply-to: (message from Andrew Hyatt on Tue, 29 Dec 2015 00:40:08 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:197105 Archived-At: > From: Andrew Hyatt > Date: Tue, 29 Dec 2015 00:40:08 -0500 > > I've put together my notes into a file I stuck in the admin section. Thanks. A few comments below. > +* 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. This paragraph is probably better to move to CONTRIBUTE. It should point to this file, which in turn should describe only the triage itself, not its importance. > +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. I think triage is more than that: it should also strive to classify the bugs according to their importance. > + 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). Triage can be done via a Web browser as well. I suggest to mention debbugs-gnu as one possibility, perhaps the preferred one, but not the only one. > + 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. Again, having the bug reproducible is not the end of triage, at least not in general. It is a good idea to use your judgment to decide whether the bug is really a bug (and if so, how important it is), a request for a new feature, or simply a rant. debbugs.gnu.org supports tags for recording the results of this process; it would be good if at least some bugs got tagged accordingly as result of the triage. > + - 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. Here, I'd suggest to request adding relevant details. Sometimes bug reports don't provide backtraces, or don't even describe the recipe in sufficient detail. If the triage supplies these details, let alone if you can come up with a simpler reproducer, adding this information will be of great value to those who will come after you to try resolving the bug. Also, if the description isn't detailed enough, it might be a good idea to ask for more detailed description, because the stuff that was left out might be the reason for not being able to reproduce the bug in the first place. > + - 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. There's a tag for that, I believe. > + 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. That mail can also say there were errors, something to mention here, I think. Thanks again for working on this (and on the triage itself).