Basic questions about the triage process

Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[Michael Albinus]

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.

Re: Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[Michael Albinus]

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.

Re: Basic questions about the triage process

[John Wiegley]

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

Re: Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[Eli Zaretskii]

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

Re: Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[Eli Zaretskii]

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

Re: Basic questions about the triage process

[Noam Postavsky]

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.

Re: Basic questions about the triage process

[Eli Zaretskii]

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

Re: Basic questions about the triage process

[Michael Albinus]

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.

Re: Basic questions about the triage process

[Eli Zaretskii]

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

Re: Basic questions about the triage process

[Michael Albinus]

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.

Re: Basic questions about the triage process

[Phillip Lord]

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

Re: Basic questions about the triage process

[Andy Moreton]

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

Re: Basic questions about the triage process

[Phillip Lord]

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

Re: Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[Xue Fuqiao]

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.

Re: Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[Lars Ingebrigtsen]

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

Re: Basic questions about the triage process

[Andrew Hyatt]

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.

Re: Basic questions about the triage process

[Lars Ingebrigtsen]

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

Re: Basic questions about the triage process

[John Wiegley]

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

RE: Basic questions about the triage process

[Drew Adams]

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

Re: Basic questions about the triage process

[Marcin Borkowski]

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

Re: Basic questions about the triage process

[Marcin Borkowski]

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

Re: Basic questions about the triage process

[CHENG Gao]

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

Re: Basic questions about the triage process

[Eli Zaretskii]

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

Re: Basic questions about the triage process

[Nikolaus Rath]

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

Re: Basic questions about the triage process

[John Wiegley]

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

RE: Basic questions about the triage process

[Drew Adams]

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

Re: Basic questions about the triage process

[Andrew Hyatt]

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.

Re: Basic questions about the triage process

[Phillip Lord]

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.

Re: Basic questions about the triage process

[Lars Magne Ingebrigtsen]

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

Re: Basic questions about the triage process

[Andrew Hyatt]

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

Re: Basic questions about the triage process

[John Wiegley]

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