unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Basic questions about the triage process
@ 2015-12-28  5:39 Andrew Hyatt
  2015-12-28  8:58 ` Michael Albinus
                   ` (2 more replies)
  0 siblings, 3 replies; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-28  5:39 UTC (permalink / raw)
  To: emacs-devel@gnu.org, jwiegley

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

John Wiegley recently put out a call on Twitter for people to help with the
closing out bugs against Emacs 25.  Seems like a real problem.  I'd like to
help!

But, pardon me for my ignorance, but I'm a bit lost as to how to get
started.  For any bug triage, there's a few necessary steps you have to
learn:

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?

2) How to triage each bug.  In this case, the basic task if clear: just try
to reproduce against emacs 25.  But if it doesn't reproduce, what then?  Do
we close the bug?  I downloaded and started using the debbugs package, but
AFAICT, it's read-only.  Seems like it should be obvious, but I can't
figure out how to close a bug in either debbugs package, or in the web
interface.

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?

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.

[-- Attachment #2: Type: text/html, Size: 1435 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28  5:39 Basic questions about the triage process Andrew Hyatt
@ 2015-12-28  8:58 ` Michael Albinus
  2015-12-28 16:25   ` Andrew Hyatt
  2015-12-28 20:24 ` John Wiegley
  2015-12-28 23:55 ` Xue Fuqiao
  2 siblings, 1 reply; 37+ messages in thread
From: Michael Albinus @ 2015-12-28  8:58 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: jwiegley, emacs-devel@gnu.org

Andrew Hyatt <ahyatt@gmail.com> writes:

Hi Andrew,

> 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?

debbugs on elpa is under rewrite these days, so I haven't pushed yet a
new version 0.8. Maybe you could download it from the elpa git?

If you want to see just the open bugs, accept all default settings when
calling "M-x debbugs-gnu". You will see all open bugs with severity
serious, important or normal. 2142 lines just now.

You can filter out the closed-but-not-archived-yet bugs by hitting "x"
(1906 lines). Hitting "x" again, all bug reports are shown again.

If you want to filter the bugs, type "/ regexp". The regexp matches
strings in the report buffer. If you, for example, want to see all bugs
with the string "tramp" in the title, type "/ tramp". This gives you 14
lines. Typing "w" returns to the full list of bugs.

If you type "R", you will see all bugs blocking the next Emacs
release. 48 lines. You can combine it with a further "x", which results
in 33 not closed bugs blocking Emacs 25.1 release. These are the most
interesting bugs to be fixed.

> 2) How to triage each bug. In this case, the basic task if clear: just
> try to reproduce against emacs 25. But if it doesn't reproduce, what
> then? Do we close the bug? I downloaded and started using the debbugs
> package, but AFAICT, it's read-only. Seems like it should be obvious,
> but I can't figure out how to close a bug in either debbugs package,
> or in the web interface. 

If your cursor points to the bug line you want to handle, type "C". This
starts a control message to be sent to the debbugs server. Use <TAB> for
completion of possible actions.

The debbugs elpa package comes with an info manual.
Try (info "(debbugs-ug)") Some commands I've mentioned above are not
documented in debbugs 0.7. See the info manual from the elpa repo.

The file debbugs-gnu.el explains the keys also in its Commentary
section.

Best regards, Michael.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28  8:58 ` Michael Albinus
@ 2015-12-28 16:25   ` Andrew Hyatt
  2015-12-28 17:35     ` Michael Albinus
  0 siblings, 1 reply; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-28 16:25 UTC (permalink / raw)
  To: Michael Albinus; +Cc: jwiegley, emacs-devel@gnu.org

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

Thanks Michael, this is a really nice summary.

One additional question: when looking at the open bugs, how do I know which
ones have already been already tested against Emacs 25?  I can see the
Emacs 25 blockers, but probably not all the bugs that are reproducible in
Emacs 25 are severe enough to be blockers, right?

On Mon, Dec 28, 2015 at 3:58 AM Michael Albinus <michael.albinus@gmx.de>
wrote:

> Andrew Hyatt <ahyatt@gmail.com> writes:
>
> Hi Andrew,
>
> > 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?
>
> debbugs on elpa is under rewrite these days, so I haven't pushed yet a
> new version 0.8. Maybe you could download it from the elpa git?
>
> If you want to see just the open bugs, accept all default settings when
> calling "M-x debbugs-gnu". You will see all open bugs with severity
> serious, important or normal. 2142 lines just now.
>
> You can filter out the closed-but-not-archived-yet bugs by hitting "x"
> (1906 lines). Hitting "x" again, all bug reports are shown again.
>
> If you want to filter the bugs, type "/ regexp". The regexp matches
> strings in the report buffer. If you, for example, want to see all bugs
> with the string "tramp" in the title, type "/ tramp". This gives you 14
> lines. Typing "w" returns to the full list of bugs.
>
> If you type "R", you will see all bugs blocking the next Emacs
> release. 48 lines. You can combine it with a further "x", which results
> in 33 not closed bugs blocking Emacs 25.1 release. These are the most
> interesting bugs to be fixed.
>
> > 2) How to triage each bug. In this case, the basic task if clear: just
> > try to reproduce against emacs 25. But if it doesn't reproduce, what
> > then? Do we close the bug? I downloaded and started using the debbugs
> > package, but AFAICT, it's read-only. Seems like it should be obvious,
> > but I can't figure out how to close a bug in either debbugs package,
> > or in the web interface.
>
> If your cursor points to the bug line you want to handle, type "C". This
> starts a control message to be sent to the debbugs server. Use <TAB> for
> completion of possible actions.
>
> The debbugs elpa package comes with an info manual.
> Try (info "(debbugs-ug)") Some commands I've mentioned above are not
> documented in debbugs 0.7. See the info manual from the elpa repo.
>
> The file debbugs-gnu.el explains the keys also in its Commentary
> section.
>
> Best regards, Michael.
>

[-- Attachment #2: Type: text/html, Size: 3297 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28 16:25   ` Andrew Hyatt
@ 2015-12-28 17:35     ` Michael Albinus
  0 siblings, 0 replies; 37+ messages in thread
From: Michael Albinus @ 2015-12-28 17:35 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: jwiegley, emacs-devel@gnu.org

Andrew Hyatt <ahyatt@gmail.com> writes:

Hi Andrew,

> One additional question: when looking at the open bugs, how do I know
> which ones have already been already tested against Emacs 25? I can
> see the Emacs 25 blockers, but probably not all the bugs that are
> reproducible in Emacs 25 are severe enough to be blockers, right?

AFAIK, there's no attribute telling towards which Emacs version a bug
has been tested. In the subject line, you see usually the Emacs version
a bug has been reported against. In theory, there is the
`found-versions' attribute of a bug. But this is not updated in
practice, once a bug has been tested with another Emacs version but the
initally reported one.

So you need to consult the corresponding emails (you get them via <RET>,
when the cursor is on the bug line).

Best regards, Michael.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28  5:39 Basic questions about the triage process Andrew Hyatt
  2015-12-28  8:58 ` Michael Albinus
@ 2015-12-28 20:24 ` John Wiegley
  2015-12-29  5:40   ` Andrew Hyatt
  2015-12-28 23:55 ` Xue Fuqiao
  2 siblings, 1 reply; 37+ messages in thread
From: John Wiegley @ 2015-12-28 20:24 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: emacs-devel@gnu.org

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

>>>>> 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.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28  5:39 Basic questions about the triage process Andrew Hyatt
  2015-12-28  8:58 ` Michael Albinus
  2015-12-28 20:24 ` John Wiegley
@ 2015-12-28 23:55 ` Xue Fuqiao
  2015-12-29  0:38   ` Andrew Hyatt
  2 siblings, 1 reply; 37+ messages in thread
From: Xue Fuqiao @ 2015-12-28 23:55 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: jwiegley, emacs-devel@gnu.org

On Mon, Dec 28, 2015 at 1:39 PM, Andrew Hyatt <ahyatt@gmail.com> wrote:

Hi Andrew,

> 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.

You can have a look at this post:
https://lists.gnu.org/archive/html/emacs-devel/2015-10/msg00441.html

Although the two documents mentioned in this post don't have answers to
all of your questions, some information in them might be helpful.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28 23:55 ` Xue Fuqiao
@ 2015-12-29  0:38   ` Andrew Hyatt
  2015-12-29  0:50     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-29  0:38 UTC (permalink / raw)
  To: Xue Fuqiao; +Cc: jwiegley, emacs-devel@gnu.org

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

Great, thanks for the replies.  I've started, and I'm going to start to
mark the ones I can't reproduce as "doneunreproducable".  "fixed" would
presumably also be fine, since at some point someone must have fixed the
bug.  If anyone has a preference, let me know.

On Mon, Dec 28, 2015 at 6:55 PM Xue Fuqiao <xfq.free@gmail.com> wrote:

> On Mon, Dec 28, 2015 at 1:39 PM, Andrew Hyatt <ahyatt@gmail.com> wrote:
>
> Hi Andrew,
>
> > 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.
>
> You can have a look at this post:
> https://lists.gnu.org/archive/html/emacs-devel/2015-10/msg00441.html
>
> Although the two documents mentioned in this post don't have answers to
> all of your questions, some information in them might be helpful.
>

[-- Attachment #2: Type: text/html, Size: 1343 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  0:38   ` Andrew Hyatt
@ 2015-12-29  0:50     ` Lars Ingebrigtsen
  2015-12-29  0:59       ` Andrew Hyatt
  0 siblings, 1 reply; 37+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-29  0:50 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: Xue Fuqiao, jwiegley, emacs-devel@gnu.org

Andrew Hyatt <ahyatt@gmail.com> writes:

> Great, thanks for the replies. I've started, and I'm going to start to
> mark the ones I can't reproduce as "doneunreproducable".

Well, even though you can't reproduce the bug doesn't mean that it
necessarily isn't a valid bug -- there may be steps necessary that the
bug reporter hasn't mentioned fully.

I usually mark bugs as "unreproducible" and then send an email to the
reporter asking whether it's gone away.  If the reporter doesn't respond
within a reasonable amount of time, then it's fine to close the bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  0:50     ` Lars Ingebrigtsen
@ 2015-12-29  0:59       ` Andrew Hyatt
  2015-12-29  1:07         ` Lars Ingebrigtsen
  2015-12-29 17:03         ` Nikolaus Rath
  0 siblings, 2 replies; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-29  0:59 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Xue Fuqiao, jwiegley, emacs-devel@gnu.org

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrew Hyatt <ahyatt@gmail.com> writes:
>
>> Great, thanks for the replies. I've started, and I'm going to start to
>> mark the ones I can't reproduce as "doneunreproducable".
>
> Well, even though you can't reproduce the bug doesn't mean that it
> necessarily isn't a valid bug -- there may be steps necessary that the
> bug reporter hasn't mentioned fully.
>
> I usually mark bugs as "unreproducible" and then send an email to the
> reporter asking whether it's gone away.  If the reporter doesn't respond
> within a reasonable amount of time, then it's fine to close the bug.

That sounds like a good idea for bugs of reasonable recentness. I'm
going through old bugs that are years old now. To me, it feels a bit
awkward to suddenly ask people to confirm anything after years have
passed - just closing seems like a more reasonable approach to me. But
I'll follow your advice for bugs in the last year. If you feel strongly
that time elapsed shouldn't matter, though, I'm happy to do it your way
all the time.

Also, I'm assuming that the bug can always be re-opened if necessary.
Maybe that isn't the case.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  0:59       ` Andrew Hyatt
@ 2015-12-29  1:07         ` Lars Ingebrigtsen
  2015-12-29  1:21           ` John Wiegley
  2015-12-29 17:03         ` Nikolaus Rath
  1 sibling, 1 reply; 37+ messages in thread
From: Lars Ingebrigtsen @ 2015-12-29  1:07 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: Xue Fuqiao, jwiegley, emacs-devel@gnu.org

Andrew Hyatt <ahyatt@gmail.com> writes:

> That sounds like a good idea for bugs of reasonable recentness. I'm
> going through old bugs that are years old now. To me, it feels a bit
> awkward to suddenly ask people to confirm anything after years have
> passed - just closing seems like a more reasonable approach to me. But
> I'll follow your advice for bugs in the last year. If you feel strongly
> that time elapsed shouldn't matter, though, I'm happy to do it your way
> all the time.

Yeah, if they're really old and aren't reproducing, closing them may be
the right thing to do.

> Also, I'm assuming that the bug can always be re-opened if necessary.
> Maybe that isn't the case.

That's the case.  But sending a form letter to the person who opened the
bug report may be polite.  Just something like

"This bug doesn't reproduce in Emacs 25, so I'm closing the bug report.
Please reopen if you're still seeing the bug."

or something.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  1:07         ` Lars Ingebrigtsen
@ 2015-12-29  1:21           ` John Wiegley
  2015-12-29  1:50             ` Drew Adams
  2015-12-29  6:46             ` CHENG Gao
  0 siblings, 2 replies; 37+ messages in thread
From: John Wiegley @ 2015-12-29  1:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Xue Fuqiao, Andrew Hyatt, emacs-devel@gnu.org

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

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrew Hyatt <ahyatt@gmail.com> writes:
>> That sounds like a good idea for bugs of reasonable recentness. I'm going
>> through old bugs that are years old now. To me, it feels a bit awkward to
>> suddenly ask people to confirm anything after years have passed - just
>> closing seems like a more reasonable approach to me. But I'll follow your
>> advice for bugs in the last year. If you feel strongly that time elapsed
>> shouldn't matter, though, I'm happy to do it your way all the time.

> Yeah, if they're really old and aren't reproducing, closing them may be the
> right thing to do.

Andrew, I think your strategy is good, but can we turn that clock back to two
years? Emacs doesn't move all that rapidly. If you can't reproduce something
From 2013 or earlier, close it as cannot reproduce with a CC to the original
reporter. Otherwise, ping the submitter with a CC to the bug address saying it
can't be reproduced, but leave it open.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* RE: Basic questions about the triage process
  2015-12-29  1:21           ` John Wiegley
@ 2015-12-29  1:50             ` Drew Adams
  2016-01-02 21:37               ` Marcin Borkowski
  2015-12-29  6:46             ` CHENG Gao
  1 sibling, 1 reply; 37+ messages in thread
From: Drew Adams @ 2015-12-29  1:50 UTC (permalink / raw)
  To: John Wiegley, Lars Ingebrigtsen; +Cc: Xue Fuqiao, Andrew Hyatt, emacs-devel

> > Yeah, if they're really old and aren't reproducing, closing them may be
> > the right thing to do.
> 
> Andrew, I think your strategy is good, but can we turn that clock back to
> two years? Emacs doesn't move all that rapidly. If you can't reproduce something
> From 2013 or earlier, close it as cannot reproduce with a CC to the original
> reporter. Otherwise, ping the submitter with a CC to the bug address saying
> it can't be reproduced, but leave it open.

FWIW, I disagree that there should be a 2-year limit, or any limit.

If Emacs Dev has never responded to a bug report, no matter
how old, then it should be treated as new.  If you cannot
seem to reproduce it now then start by asking for more info -
and not after closing it, just as you would do for a bug
reported yesterday.

If Emac Dev has responded previously, that's a different
story.  But there is a giant backlog of bugs, and some of
them are several years old (perhaps even many years old)
and have never been responded to.

What should count, if you must count time elapsed, is the
time since the last attempt by a bug fixer to obtain info.
If no one has ever tried, then the clock should be reset
to zero.

(Just one opinion.)



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-28 20:24 ` John Wiegley
@ 2015-12-29  5:40   ` Andrew Hyatt
  2015-12-29 17:12     ` Eli Zaretskii
  2016-01-07 21:04     ` Phillip Lord
  0 siblings, 2 replies; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-29  5:40 UTC (permalink / raw)
  To: emacs-devel@gnu.org

[-- 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)


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  1:21           ` John Wiegley
  2015-12-29  1:50             ` Drew Adams
@ 2015-12-29  6:46             ` CHENG Gao
  2015-12-29 15:50               ` Eli Zaretskii
  1 sibling, 1 reply; 37+ messages in thread
From: CHENG Gao @ 2015-12-29  6:46 UTC (permalink / raw)
  To: emacs-devel

*On Mon, 28 Dec 2015 17:21:22 -0800
* Also sprach John Wiegley <jwiegley@gmail.com>:

>>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>> That sounds like a good idea for bugs of reasonable recentness. I'm
>>> going through old bugs that are years old now. To me, it feels a
>>> bit awkward to suddenly ask people to confirm anything after years
>>> have passed - just closing seems like a more reasonable approach to
>>> me. But I'll follow your advice for bugs in the last year. If you
>>> feel strongly that time elapsed shouldn't matter, though, I'm happy
>>> to do it your way all the time.
>
>> Yeah, if they're really old and aren't reproducing, closing them may
>> be the right thing to do.
>
> Andrew, I think your strategy is good, but can we turn that clock back
> to two years? Emacs doesn't move all that rapidly. If you can't
> reproduce something From 2013 or earlier, close it as cannot reproduce
> with a CC to the original reporter. Otherwise, ping the submitter with
> a CC to the bug address saying it can't be reproduced, but leave it
> open.

Maybe the strategy needs a clarification of version supporting policy or
should be based on said policy if it exists.

Say for example 24.x line supported while 23.x support dropped.

The priority could be as below:

Number one: emacs-25 branch related
Should have highest priority since they'll block the release.

Number two: emacs git
They slow down moving train.

Number three: emacs 24.x
Maybe a policy to include accumulated fixes in a new release untill
support dropped, for example yearly bugfix on Dec. 25 or Dec. 31.
Bug fixes only, no new feature backports.

Number four: emacs 23.x/22.x etc (justing kidding. No kidding?)
If bothered by "cannot sleep thinking users are abandoned in darkness"
syndrome, accept users submitted patches and release accumulated bugfix
minor version each year as above.

Maybe a cycling poicy can be built.

Just my RMB2 cents.




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  6:46             ` CHENG Gao
@ 2015-12-29 15:50               ` Eli Zaretskii
  0 siblings, 0 replies; 37+ messages in thread
From: Eli Zaretskii @ 2015-12-29 15:50 UTC (permalink / raw)
  To: CHENG Gao; +Cc: emacs-devel

> From: CHENG Gao <chenggao@royau.me>
> Date: Tue, 29 Dec 2015 14:46:48 +0800
> 
> > Andrew, I think your strategy is good, but can we turn that clock back
> > to two years? Emacs doesn't move all that rapidly. If you can't
> > reproduce something From 2013 or earlier, close it as cannot reproduce
> > with a CC to the original reporter. Otherwise, ping the submitter with
> > a CC to the bug address saying it can't be reproduced, but leave it
> > open.
> 
> Maybe the strategy needs a clarification of version supporting policy or
> should be based on said policy if it exists.

We always support only the latest released version, but if a bug
reported in an old version still exists in the latest one, we try
fixing it in the next release.

IOW, I don't see any relation between version support policy and the
strategy of triage of bug reports.

> The priority could be as below:
> 
> Number one: emacs-25 branch related
> Should have highest priority since they'll block the release.
> 
> Number two: emacs git
> They slow down moving train.
> 
> Number three: emacs 24.x
> Maybe a policy to include accumulated fixes in a new release untill
> support dropped, for example yearly bugfix on Dec. 25 or Dec. 31.
> Bug fixes only, no new feature backports.
> 
> Number four: emacs 23.x/22.x etc (justing kidding. No kidding?)
> If bothered by "cannot sleep thinking users are abandoned in darkness"
> syndrome, accept users submitted patches and release accumulated bugfix
> minor version each year as above.

I don't think triage should depend on bug priority.  On the contrary,
priority can only be established once the triage has been done; thus,
triage should always have the highest priority, IMO.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  0:59       ` Andrew Hyatt
  2015-12-29  1:07         ` Lars Ingebrigtsen
@ 2015-12-29 17:03         ` Nikolaus Rath
  2015-12-29 17:16           ` John Wiegley
  2015-12-29 17:50           ` Drew Adams
  1 sibling, 2 replies; 37+ messages in thread
From: Nikolaus Rath @ 2015-12-29 17:03 UTC (permalink / raw)
  To: emacs-devel

On Dec 28 2015, Andrew Hyatt <ahyatt@gmail.com> wrote:
> To me, it feels a bit
> awkward to suddenly ask people to confirm anything after years have
> passed - just closing seems like a more reasonable approach to me.

As a reporter, I can assure you that I feel exactly the other way
around. It takes time to write good bugreports, and if they languish for
several years only to eventually get closed because they "seem to have
been fixed" makes me angry. I consider a polite "I tried to reproduce it
but failed, could you confirm that this is fixed for you as well?" to be
much more respectful of my time and contribution.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  5:40   ` Andrew Hyatt
@ 2015-12-29 17:12     ` Eli Zaretskii
  2015-12-30  0:22       ` Andrew Hyatt
  2016-01-07 21:04     ` Phillip Lord
  1 sibling, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2015-12-29 17:12 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: emacs-devel

> From: Andrew Hyatt <ahyatt@gmail.com>
> 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).



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29 17:03         ` Nikolaus Rath
@ 2015-12-29 17:16           ` John Wiegley
  2015-12-29 17:50           ` Drew Adams
  1 sibling, 0 replies; 37+ messages in thread
From: John Wiegley @ 2015-12-29 17:16 UTC (permalink / raw)
  To: emacs-devel

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

>>>>> Nikolaus Rath <Nikolaus@rath.org> writes:

> On Dec 28 2015, Andrew Hyatt <ahyatt@gmail.com> wrote:
>> To me, it feels a bit awkward to suddenly ask people to confirm anything
>> after years have passed - just closing seems like a more reasonable
>> approach to me.

> As a reporter, I can assure you that I feel exactly the other way around.

On other projects, I've sent such "query mails" many years after the original
report, and no one was ever bothered by it. And I've received them myself,
often only to say "I don't use system X anymore", but it didn't upset me.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* RE: Basic questions about the triage process
  2015-12-29 17:03         ` Nikolaus Rath
  2015-12-29 17:16           ` John Wiegley
@ 2015-12-29 17:50           ` Drew Adams
  2015-12-29 23:36             ` Andrew Hyatt
  1 sibling, 1 reply; 37+ messages in thread
From: Drew Adams @ 2015-12-29 17:50 UTC (permalink / raw)
  To: Nikolaus Rath, emacs-devel

> > To me, it feels a bit
> > awkward to suddenly ask people to confirm anything after years have
> > passed - just closing seems like a more reasonable approach to me.
> 
> As a reporter, I can assure you that I feel exactly the other way
> around. It takes time to write good bugreports, and if they languish for
> several years only to eventually get closed because they "seem to have
> been fixed" makes me angry.
>
> I consider a polite "I tried to reproduce it
> but failed, could you confirm that this is fixed for you as well?" to be
> much more respectful of my time and contribution.

100% agreement.  Users who write bug reports are helping.
Even more important: they are actively _trying_ to help.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29 17:50           ` Drew Adams
@ 2015-12-29 23:36             ` Andrew Hyatt
  2016-01-07 21:09               ` Phillip Lord
  0 siblings, 1 reply; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-29 23:36 UTC (permalink / raw)
  To: Drew Adams; +Cc: Nikolaus Rath, emacs-devel


Sounds like there's some widespread feeling that we should ask first
regardless of how much time has passed. The difference seems a bit minor
to me (the real issue is the languishing of bugs, I think), because the
only difference is whether we close before the email or after waiting
for a response. But I'll just ask first, give people a few weeks to
respond, and then close the bug if there's no response.

FWIW, on the bugs I looked at yesterday, a few bounced from the
reporter's email, so I'll just close them immediately if that happens.

Drew Adams <drew.adams@oracle.com> writes:

>> > To me, it feels a bit
>> > awkward to suddenly ask people to confirm anything after years have
>> > passed - just closing seems like a more reasonable approach to me.
>> 
>> As a reporter, I can assure you that I feel exactly the other way
>> around. It takes time to write good bugreports, and if they languish for
>> several years only to eventually get closed because they "seem to have
>> been fixed" makes me angry.
>>
>> I consider a polite "I tried to reproduce it
>> but failed, could you confirm that this is fixed for you as well?" to be
>> much more respectful of my time and contribution.
>
> 100% agreement.  Users who write bug reports are helping.
> Even more important: they are actively _trying_ to help.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29 17:12     ` Eli Zaretskii
@ 2015-12-30  0:22       ` Andrew Hyatt
  2015-12-30 17:21         ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Andrew Hyatt @ 2015-12-30  0:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrew Hyatt <ahyatt@gmail.com>
>> 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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Version 2 of triage notes patch --]
[-- Type: text/x-patch, Size: 3928 bytes --]

From 3e496267725a6a44e32439fe8934ebda5a33f150 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.

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)


^ permalink raw reply related	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-30  0:22       ` Andrew Hyatt
@ 2015-12-30 17:21         ` Eli Zaretskii
  2015-12-31  1:19           ` Noam Postavsky
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2015-12-30 17:21 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: emacs-devel

> From: Andrew Hyatt <ahyatt@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 29 Dec 2015 19:22:27 -0500
> 
> >> +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.

You assume that old bugs already underwent this procedure, and if they
did, their category is still correct.  But neither of these assumption
is necessarily true.  Some bugs were triaged, others (I suspect most
of them) were not.  Moreover, their current category might very well
be inaccurate, certainly if many years went by.

So I think some effort should go into verifying that a bug does have a
category that we still think to be correct.

> >> +  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.

One needs to read the error message and resubmit the control message
modified as appropriate.  E.g., one example I tend to bump into is
when I merge a bug with another one, and debbugs refuses because their
state is different -- in that case one needs to change the state of
one of the two bugs and then resubmit the merge directive.

Thanks.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-30 17:21         ` Eli Zaretskii
@ 2015-12-31  1:19           ` Noam Postavsky
  2015-12-31  3:38             ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Noam Postavsky @ 2015-12-31  1:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Andrew Hyatt, emacs-devel

On Wed, Dec 30, 2015 at 12:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> One needs to read the error message and resubmit the control message
> modified as appropriate.  E.g., one example I tend to bump into is
> when I merge a bug with another one, and debbugs refuses because their
> state is different -- in that case one needs to change the state of
> one of the two bugs and then resubmit the merge directive.

Is there some reason not to use forcemerge?

http://git.savannah.gnu.org/cgit/emacs.git/tree/admin/notes/bugtracker?id=emacs-24.5#n345

    *** Forcing a merge:
    Like 'merge', but bugs need not be in the same state.  The packages
    must still match though (see 'reassign' below).  The first one listed
    is the master.  E.g.:

    forcemerge 123 124 125 ...

    Note: you cannot merge with an archived bug - you must unarchive it first.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-31  1:19           ` Noam Postavsky
@ 2015-12-31  3:38             ` Eli Zaretskii
  2015-12-31  9:06               ` Michael Albinus
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2015-12-31  3:38 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: ahyatt, emacs-devel

> Date: Wed, 30 Dec 2015 20:19:27 -0500
> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: Andrew Hyatt <ahyatt@gmail.com>, emacs-devel@gnu.org
> 
> On Wed, Dec 30, 2015 at 12:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > One needs to read the error message and resubmit the control message
> > modified as appropriate.  E.g., one example I tend to bump into is
> > when I merge a bug with another one, and debbugs refuses because their
> > state is different -- in that case one needs to change the state of
> > one of the two bugs and then resubmit the merge directive.
> 
> Is there some reason not to use forcemerge?

It still requires a new control message, so what I said is still
valid.  And as long as you do have to send a new control message, why
not do it right?

Also, note this caveat:

>     Note: you cannot merge with an archived bug - you must unarchive it first.

IOW, even forcemerge won't always work.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-31  3:38             ` Eli Zaretskii
@ 2015-12-31  9:06               ` Michael Albinus
  2015-12-31 13:49                 ` Eli Zaretskii
  0 siblings, 1 reply; 37+ messages in thread
From: Michael Albinus @ 2015-12-31  9:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ahyatt, emacs-devel, Noam Postavsky

Eli Zaretskii <eliz@gnu.org> writes:

>> On Wed, Dec 30, 2015 at 12:21 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> >
>> > One needs to read the error message and resubmit the control message
>> > modified as appropriate.  E.g., one example I tend to bump into is
>> > when I merge a bug with another one, and debbugs refuses because their
>> > state is different -- in that case one needs to change the state of
>> > one of the two bugs and then resubmit the merge directive.
>> 
>> Is there some reason not to use forcemerge?
>
> It still requires a new control message, so what I said is still
> valid.  And as long as you do have to send a new control message, why
> not do it right?
>
> Also, note this caveat:
>
>>     Note: you cannot merge with an archived bug - you must unarchive it first.
>
> IOW, even forcemerge won't always work.

debbugs-gnu could automate this scenario, in case it is desired. Just
request it :-)

Best regards, Michael.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-31  9:06               ` Michael Albinus
@ 2015-12-31 13:49                 ` Eli Zaretskii
  2015-12-31 13:57                   ` Michael Albinus
  0 siblings, 1 reply; 37+ messages in thread
From: Eli Zaretskii @ 2015-12-31 13:49 UTC (permalink / raw)
  To: Michael Albinus; +Cc: ahyatt, emacs-devel, npostavs

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Noam Postavsky <npostavs@users.sourceforge.net>,  ahyatt@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 31 Dec 2015 10:06:05 +0100
> 
> >>     Note: you cannot merge with an archived bug - you must unarchive it first.
> >
> > IOW, even forcemerge won't always work.
> 
> debbugs-gnu could automate this scenario, in case it is desired. Just
> request it :-)

Automation is always welcome, although I'm unsure how can you know in
advance what's TRT in each specific case.

Thanks.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-31 13:49                 ` Eli Zaretskii
@ 2015-12-31 13:57                   ` Michael Albinus
  0 siblings, 0 replies; 37+ messages in thread
From: Michael Albinus @ 2015-12-31 13:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: ahyatt, emacs-devel, npostavs

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Note: you cannot merge with an archived bug - you must unarchive
>> > it first.
>> >
>> > IOW, even forcemerge won't always work.
>> 
>> debbugs-gnu could automate this scenario, in case it is desired. Just
>> request it :-)
>
> Automation is always welcome, although I'm unsure how can you know in
> advance what's TRT in each specific case.

debbugs-gnu supports already the forcemerge control. It could check
whether one of the involved bugs is archived, and unarchive it first.

Or unarchive all involved bugs without a check, before requesting
forcemerge. This would be a null operation for not archived bugs, but
this doesn't harm I believe. To be tested.

> Thanks.

Best regards, Michael.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  1:50             ` Drew Adams
@ 2016-01-02 21:37               ` Marcin Borkowski
  2016-02-15 20:04                 ` Marcin Borkowski
  0 siblings, 1 reply; 37+ messages in thread
From: Marcin Borkowski @ 2016-01-02 21:37 UTC (permalink / raw)
  To: Drew Adams
  Cc: Xue Fuqiao, John Wiegley, Lars Ingebrigtsen, Andrew Hyatt,
	emacs-devel

Hi,

I'm starting to work on bugs, too.

On 2015-12-29, at 02:50, Drew Adams <drew.adams@oracle.com> wrote:

>> > Yeah, if they're really old and aren't reproducing, closing them may be
>> > the right thing to do.
>> 
>> Andrew, I think your strategy is good, but can we turn that clock back to
>> two years? Emacs doesn't move all that rapidly. If you can't reproduce something
>> From 2013 or earlier, close it as cannot reproduce with a CC to the original
>> reporter. Otherwise, ping the submitter with a CC to the bug address saying
>> it can't be reproduced, but leave it open.
>
> FWIW, I disagree that there should be a 2-year limit, or any limit.
>
> If Emacs Dev has never responded to a bug report, no matter
> how old, then it should be treated as new.  If you cannot
> seem to reproduce it now then start by asking for more info -
> and not after closing it, just as you would do for a bug
> reported yesterday.
>
> If Emac Dev has responded previously, that's a different
> story.  But there is a giant backlog of bugs, and some of
> them are several years old (perhaps even many years old)
> and have never been responded to.
>
> What should count, if you must count time elapsed, is the
> time since the last attempt by a bug fixer to obtain info.
> If no one has ever tried, then the clock should be reset
> to zero.
>
> (Just one opinion.)

And another one, too - I agree with Drew on this

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29  5:40   ` Andrew Hyatt
  2015-12-29 17:12     ` Eli Zaretskii
@ 2016-01-07 21:04     ` Phillip Lord
  2016-01-07 22:05       ` Andy Moreton
  1 sibling, 1 reply; 37+ messages in thread
From: Phillip Lord @ 2016-01-07 21:04 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: emacs-devel@gnu.org



Andrew Hyatt <ahyatt@gmail.com> writes:

> John Wiegley <jwiegley@gmail.com> writes:
>
>>>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>
>> 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.

Would you object to changing the name of this file to "bug-triage". It
should say "bug" somewhere!

Phil



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2015-12-29 23:36             ` Andrew Hyatt
@ 2016-01-07 21:09               ` Phillip Lord
  2016-01-07 21:28                 ` Lars Magne Ingebrigtsen
  0 siblings, 1 reply; 37+ messages in thread
From: Phillip Lord @ 2016-01-07 21:09 UTC (permalink / raw)
  To: Andrew Hyatt; +Cc: Nikolaus Rath, Drew Adams, emacs-devel


Is there a "pending-closure" tag, that can be used to help the clean up?
Then one person could send the "I think this is outdated now" email, and
another close it later.

Phil

Andrew Hyatt <ahyatt@gmail.com> writes:

> Sounds like there's some widespread feeling that we should ask first
> regardless of how much time has passed. The difference seems a bit minor
> to me (the real issue is the languishing of bugs, I think), because the
> only difference is whether we close before the email or after waiting
> for a response. But I'll just ask first, give people a few weeks to
> respond, and then close the bug if there's no response.
>
> FWIW, on the bugs I looked at yesterday, a few bounced from the
> reporter's email, so I'll just close them immediately if that happens.
>
> Drew Adams <drew.adams@oracle.com> writes:
>
>>> > To me, it feels a bit
>>> > awkward to suddenly ask people to confirm anything after years have
>>> > passed - just closing seems like a more reasonable approach to me.
>>> 
>>> As a reporter, I can assure you that I feel exactly the other way
>>> around. It takes time to write good bugreports, and if they languish for
>>> several years only to eventually get closed because they "seem to have
>>> been fixed" makes me angry.
>>>
>>> I consider a polite "I tried to reproduce it
>>> but failed, could you confirm that this is fixed for you as well?" to be
>>> much more respectful of my time and contribution.
>>
>> 100% agreement.  Users who write bug reports are helping.
>> Even more important: they are actively _trying_ to help.



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-07 21:09               ` Phillip Lord
@ 2016-01-07 21:28                 ` Lars Magne Ingebrigtsen
  2016-01-09  3:47                   ` Andrew Hyatt
  0 siblings, 1 reply; 37+ messages in thread
From: Lars Magne Ingebrigtsen @ 2016-01-07 21:28 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Andrew Hyatt, Nikolaus Rath, Drew Adams, emacs-devel

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Is there a "pending-closure" tag, that can be used to help the clean up?
> Then one person could send the "I think this is outdated now" email, and
> another close it later.

That's basically "moreinfo".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-07 21:04     ` Phillip Lord
@ 2016-01-07 22:05       ` Andy Moreton
  2016-01-07 22:40         ` Phillip Lord
  0 siblings, 1 reply; 37+ messages in thread
From: Andy Moreton @ 2016-01-07 22:05 UTC (permalink / raw)
  To: emacs-devel

On Thu 07 Jan 2016, Phillip Lord wrote:

> Andrew Hyatt <ahyatt@gmail.com> writes:
>
>> John Wiegley <jwiegley@gmail.com> writes:
>>
>>>>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>>
>>> 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.
>
> Would you object to changing the name of this file to "bug-triage". It
> should say "bug" somewhere!

Why ? Not all problems raised in an issue tracker are actually bugs
(user error, misconfiguration, distro packaging issues etc).

    AndyM




^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-07 22:05       ` Andy Moreton
@ 2016-01-07 22:40         ` Phillip Lord
  2016-01-09  3:46           ` Andrew Hyatt
  0 siblings, 1 reply; 37+ messages in thread
From: Phillip Lord @ 2016-01-07 22:40 UTC (permalink / raw)
  To: Andy Moreton; +Cc: emacs-devel

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Thu 07 Jan 2016, Phillip Lord wrote:
>
>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>
>>> John Wiegley <jwiegley@gmail.com> writes:
>>>
>>>>>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>>>
>>>> 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.
>>
>> Would you object to changing the name of this file to "bug-triage". It
>> should say "bug" somewhere!
>
> Why ? Not all problems raised in an issue tracker are actually bugs
> (user error, misconfiguration, distro packaging issues etc).


"issue-triage" would also be fine. But "bug" is generally accepted here.
"debbugs", "bugtracker" and so on.

Just trying to increase discoverability.

Phil



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-07 22:40         ` Phillip Lord
@ 2016-01-09  3:46           ` Andrew Hyatt
  0 siblings, 0 replies; 37+ messages in thread
From: Andrew Hyatt @ 2016-01-09  3:46 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Andy Moreton, emacs-devel

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Andy Moreton <andrewjmoreton@gmail.com> writes:
>
>> On Thu 07 Jan 2016, Phillip Lord wrote:
>>
>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>>
>>>> John Wiegley <jwiegley@gmail.com> writes:
>>>>
>>>>>>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>>>>>
>>>>> 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.
>>>
>>> Would you object to changing the name of this file to "bug-triage". It
>>> should say "bug" somewhere!
>>
>> Why ? Not all problems raised in an issue tracker are actually bugs
>> (user error, misconfiguration, distro packaging issues etc).
>
>
> "issue-triage" would also be fine. But "bug" is generally accepted here.
> "debbugs", "bugtracker" and so on.
>
> Just trying to increase discoverability.

I agree, I'll change this to bug-triage.  FWIW, these systems always
seem to be referred to as bug systems, even though they always end up
handling other things besides bugs.

>
> Phil



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-07 21:28                 ` Lars Magne Ingebrigtsen
@ 2016-01-09  3:47                   ` Andrew Hyatt
  2016-01-09 20:56                     ` John Wiegley
  0 siblings, 1 reply; 37+ messages in thread
From: Andrew Hyatt @ 2016-01-09  3:47 UTC (permalink / raw)
  To: Lars Magne Ingebrigtsen
  Cc: Nikolaus Rath, emacs-devel, Drew Adams, Phillip Lord

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>> Is there a "pending-closure" tag, that can be used to help the clean up?
>> Then one person could send the "I think this is outdated now" email, and
>> another close it later.
>
> That's basically "moreinfo".

I've been using the "unreproducible" tag as just this sort of tag - it
means that it can't be reproduced at least by me, and if no one can
reproduce it within a few weeks, it should be turned into
"doneunreproducible".  I've detailed this process in the
admin/notes/triage file (which I'll soon rename to admin/notes/bug-triage).



^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-09  3:47                   ` Andrew Hyatt
@ 2016-01-09 20:56                     ` John Wiegley
  0 siblings, 0 replies; 37+ messages in thread
From: John Wiegley @ 2016-01-09 20:56 UTC (permalink / raw)
  To: Andrew Hyatt
  Cc: Lars Magne Ingebrigtsen, Phillip Lord, Nikolaus Rath, Drew Adams,
	emacs-devel

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

>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:

>> That's basically "moreinfo".

> I've been using the "unreproducible" tag as just this sort of tag - it means
> that it can't be reproduced at least by me, and if no one can reproduce it
> within a few weeks, it should be turned into "doneunreproducible". I've
> detailed this process in the admin/notes/triage file (which I'll soon rename
> to admin/notes/bug-triage).

Indeed, I had thought "moreinfo" meant: I need more information before I can
even attempt to reproduce this.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

^ permalink raw reply	[flat|nested] 37+ messages in thread

* Re: Basic questions about the triage process
  2016-01-02 21:37               ` Marcin Borkowski
@ 2016-02-15 20:04                 ` Marcin Borkowski
  0 siblings, 0 replies; 37+ messages in thread
From: Marcin Borkowski @ 2016-02-15 20:04 UTC (permalink / raw)
  To: Drew Adams
  Cc: Xue Fuqiao, John Wiegley, Lars Ingebrigtsen, Andrew Hyatt,
	emacs-devel


On 2016-01-02, at 22:37, Marcin Borkowski <mbork@mbork.pl> wrote:

> Hi,
>
> I'm starting to work on bugs, too.

Hi,

I've been doing a bit of work on bugs recently, and I got to bugs from
2014.  Should I continue with more recent bugs?  What would be
a valuable (from the point of view of Emacs devs) use of my limited time
for that?

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University



^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2016-02-15 20:04 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-28  5:39 Basic questions about the triage process Andrew Hyatt
2015-12-28  8:58 ` Michael Albinus
2015-12-28 16:25   ` Andrew Hyatt
2015-12-28 17:35     ` Michael Albinus
2015-12-28 20:24 ` John Wiegley
2015-12-29  5:40   ` Andrew Hyatt
2015-12-29 17:12     ` Eli Zaretskii
2015-12-30  0:22       ` Andrew Hyatt
2015-12-30 17:21         ` Eli Zaretskii
2015-12-31  1:19           ` Noam Postavsky
2015-12-31  3:38             ` Eli Zaretskii
2015-12-31  9:06               ` Michael Albinus
2015-12-31 13:49                 ` Eli Zaretskii
2015-12-31 13:57                   ` Michael Albinus
2016-01-07 21:04     ` Phillip Lord
2016-01-07 22:05       ` Andy Moreton
2016-01-07 22:40         ` Phillip Lord
2016-01-09  3:46           ` Andrew Hyatt
2015-12-28 23:55 ` Xue Fuqiao
2015-12-29  0:38   ` Andrew Hyatt
2015-12-29  0:50     ` Lars Ingebrigtsen
2015-12-29  0:59       ` Andrew Hyatt
2015-12-29  1:07         ` Lars Ingebrigtsen
2015-12-29  1:21           ` John Wiegley
2015-12-29  1:50             ` Drew Adams
2016-01-02 21:37               ` Marcin Borkowski
2016-02-15 20:04                 ` Marcin Borkowski
2015-12-29  6:46             ` CHENG Gao
2015-12-29 15:50               ` Eli Zaretskii
2015-12-29 17:03         ` Nikolaus Rath
2015-12-29 17:16           ` John Wiegley
2015-12-29 17:50           ` Drew Adams
2015-12-29 23:36             ` Andrew Hyatt
2016-01-07 21:09               ` Phillip Lord
2016-01-07 21:28                 ` Lars Magne Ingebrigtsen
2016-01-09  3:47                   ` Andrew Hyatt
2016-01-09 20:56                     ` John Wiegley

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).