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 19:22:27 -0500 Message-ID: References: <83ege5dvra.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: ger.gmane.org 1451434970 27839 80.91.229.3 (30 Dec 2015 00:22:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 30 Dec 2015 00:22:50 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 30 01:22:43 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 1aE4XI-0002BG-Rn for ged-emacs-devel@m.gmane.org; Wed, 30 Dec 2015 01:22:41 +0100 Original-Received: from localhost ([::1]:50686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE4XH-00038t-Sk for ged-emacs-devel@m.gmane.org; Tue, 29 Dec 2015 19:22:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49543) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE4XD-00038W-Th for emacs-devel@gnu.org; Tue, 29 Dec 2015 19:22:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aE4XA-0001vT-Hn for emacs-devel@gnu.org; Tue, 29 Dec 2015 19:22:35 -0500 Original-Received: from mail-qg0-x22f.google.com ([2607:f8b0:400d:c04::22f]:34613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aE4XA-0001vO-CO; Tue, 29 Dec 2015 19:22:32 -0500 Original-Received: by mail-qg0-x22f.google.com with SMTP id 6so97151440qgy.1; Tue, 29 Dec 2015 16:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=nz24gKuIeKx8PgU3kr41qJVgxqyRhtQcn04iHYWAcZg=; b=figwF+moIqpzfphK1OMJPV29UVl1lV0vbcZZhPy+8s/kYVgND36nVaEB8PNpEjpokm jhCsrr2J3Wrzg9/NEACbNMMo/kQi5iieIBhrEguXXcKtdFO84MxCUpzEdx2dNiAQ1YhE JF7/TCAqxIWP8V5PoTjQDEXfH4RNCgRjKhBtlJr3DlpElaTgyMIKxCnQaMgZSHzeSLlO 6JlF2yZavQGglvEvSKu93SZLjbtI3Nc77IPW4CLF8qPWLIDMFOBXKc7KDVz8j2MsxOL2 xqLAsoOwU9Y6fbpHRDtdmIEMZKjj3+0BxrukH4NyMplG/H7g+xUexm8pVWdU2KSYfUMH C5sw== X-Received: by 10.140.98.197 with SMTP id o63mr81887035qge.43.1451434951847; Tue, 29 Dec 2015 16:22:31 -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 133sm22938641qhu.9.2015.12.29.16.22.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Dec 2015 16:22:29 -0800 (PST) In-Reply-To: <83ege5dvra.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Dec 2015 19:12:25 +0200") 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::22f 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:197150 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> 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. OK, I've done so (see the modified patch I've attached). This probably needs a bit more work since we want to talk about more kinds of triage as well (notably the triaging of new bugs), eventually. > >> +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. Yes, but isn't that more about triaging new bugs? I'm not writing about that yet - but if someone tells me how to triage new bugs I'm happy to write it up. > >> + 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. Done. > >> + 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. Again, I think this right, but for new bug triage which I haven't written up yet. For the bug backlog, I'm assuming someone has already taken a pass at each bug. > >> + - 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. Done (although I split this up into two parts - one new bullet point, another as part of the text on what to do if you can reproduce the issue). > >> + - 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. We can just use the "unreproducible" tag. Sounds like a good idea. I'll add that. > >> + 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. Mentioned, but I'm a bit at a loss on what to say if there were errors. > > Thanks again for working on this (and on the triage itself). No problem. I've also removed, by popular demand, the distinction between pre-and-post 2 years old. Now we'll always just ask first. I've also fixed a few spelling and grammar errors. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-Add-a-file-detailing-how-to-triage-bugs.patch Content-Description: Version 2 of triage notes patch >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) --=-=-=--