Unanswered Emacs Problem Reports 40+ Months

Unanswered Emacs Problem Reports 40+ Months

[Christian Bryant]

Hello,

I'll be embarking on a contact effort over the next month
to query problem reports for Emacs from oldest on up
as to whether the bug is still relevant, and if not, request
that reporters please close the report.  If the bug _is_ still
relevant, I'll ask them to update the bug report.  This effort
will apply to bugs older than 40 months, starting with the
oldest reports, as noted in recent tracker data [1].

I'll make no initial attempt to cross-reference bugs for
duplication, fixes in later releases, or other troubleshooting
efforts.  I'll contact Stefan Monnier directly with concerns
and etc.

I'm reviewing earlier efforts at this for ideas to write up
some polite and encouraging text.

Drop me a line if you have any requests/recommendations/questions.

Thanks, and cheers!

[1] 
http://lists.gnu.org/archive/html/emacs-bug-tracker/2013-10/msg00126.html

-- 
Christian Bryant
GNU+Linux-libre = Freedom
http://www.gnulinuxlibre.org
IRC: #gnulinuxlibre @freenode

Re: Unanswered Emacs Problem Reports 40+ Months

[Glenn Morris]

Christian Bryant wrote:

> I'll be embarking on a contact effort over the next month to query
> problem reports for Emacs from oldest on up as to whether the bug is
> still relevant, and if not, request that reporters please close the
> report. If the bug _is_ still relevant, I'll ask them to update the
> bug report. This effort will apply to bugs older than 40 months,
> starting with the oldest reports, as noted in recent tracker data [1].

Thanks. We certainly need help with bug reports.

I'm not exactly sure what you are proposing to do, though.
Would this be a totally automatic process, in which every old, open bug
report simply gets a mail asking the OP to confirm it is still relevant?
Because I'm not sure that is a very useful thing to do. I don't like it
when eg certain distributions automatically close all bugs filed against
previous releases unless people confirm they still exist in the latest
release.

> I'll make no initial attempt to cross-reference bugs for duplication,
> fixes in later releases, or other troubleshooting efforts.

See, I kind of think this is the thing that _should_ be done first (I've
tried to do it in the past). Once someone has filed a bug, the burden is
on us as developers to do something about it. Whether that's requesting
more info, fixing it, saying we won't fix it, saying it's not a bug, or
saying that it's not a priority right now.

I don't really know what's going to happen with all the old Emacs bugs
that are still open. It seems impossible to ever fix them all.
But does that mean we should just declare bankruptcy and close them?
I don't know...

If every person with commit access to Emacs dealt with 15 bugs,
that would be all of them. ;)

Sometimes I look through the old ones and see if I can do anything about
them. I do think this requires actually reading them, though, not simply
sending a form email.

Re: Unanswered Emacs Problem Reports 40+ Months

[Christian Bryant]

On 10/24/2013 12:46 AM, Glenn Morris wrote:
> I'm not exactly sure what you are proposing to do, though.
> Would this be a totally automatic process, in which every old, open bug
> report simply gets a mail asking the OP to confirm it is still relevant?

That was my initial intent, yes.

> Because I'm not sure that is a very useful thing to do. I don't like it
> when eg certain distributions automatically close all bugs filed against
> previous releases unless people confirm they still exist in the latest
> release.

Absolutely agreed.  I will be asking the reporter to confirm the problem
continues to exist in the latest release.  Is there a concern some users
may simply close bugs without testing?

>> I'll make no initial attempt to cross-reference bugs for duplication,
>> fixes in later releases, or other troubleshooting efforts.
>
> See, I kind of think this is the thing that _should_ be done first (I've
> tried to do it in the past). Once someone has filed a bug, the burden is
> on us as developers to do something about it. Whether that's requesting
> more info, fixing it, saying we won't fix it, saying it's not a bug, or
> saying that it's not a priority right now.

For 40 month old bugs and younger, I would absolutely agree.  However,
due to the age of the bugs I will be emailing reporters a form email on,
I think it may be the best route to get some clean-up on those 68 months
to 41 months old bugs.

> I don't really know what's going to happen with all the old Emacs bugs
> that are still open. It seems impossible to ever fix them all.
> But does that mean we should just declare bankruptcy and close them?
> I don't know...

I would say "no" on bankruptcy, certainly.  Perhaps the form email is
the better of two evils?

> If every person with commit access to Emacs dealt with 15 bugs,
> that would be all of them. ;)

Perhaps this discussion will get some folks thinking along those lines!
:-)

- CB

Re: Unanswered Emacs Problem Reports 40+ Months

[Stefan Monnier]

> Would this be a totally automatic process, in which every old, open bug
> report simply gets a mail asking the OP to confirm it is still relevant?

I think so, yes.

> Because I'm not sure that is a very useful thing to do. I don't like it
> when eg certain distributions automatically close all bugs filed against
> previous releases unless people confirm they still exist in the latest
> release.

We're not talking about closing the bugs, but confirming that the bug is
still relevant.  Tho, in the absence of a reply by the bug-submitter
within a month (say), we could also decide to close the bug.

> If every person with commit access to Emacs dealt with 15 bugs,
> that would be all of them. ;)

The idea is to ask the bug-submitter's help.

I think it would also help to try and classify those old bugs into
different categories:
- bugs that are waiting for more info from the submitter.
- bugs to which we did reply and then things stalled (e.g. because we
  don't know how to fix them, lack of manpower, ...).
- bugs that have not seen any activity at all: not even a "hmm, thanks,
  we'll look into it".  These then get subdivided into:
  - author is a well-known contributor, so it's acceptable.
  - else, this is a serious lack of consideration, we should at least
    tell him "thank you for reporting this problem and sorry we don't
    have the manpower to handle it".
I think this classification can be made automatically/heuristically
by checking if the last message was from a developer.


        Stefan

Re: Unanswered Emacs Problem Reports 40+ Months

[Glenn Morris]

Stefan Monnier wrote:

> We're not talking about closing the bugs, but confirming that the bug is
> still relevant.  Tho, in the absence of a reply by the bug-submitter
> within a month (say), we could also decide to close the bug.

I imagine most responses will be of two kinds:

1) No reply. Then what?

2) A slightly annoyed "yes, of course my wishlist/doc bug/whatever"
still applies, didn't you read it/test it/try my patch?".

The useful replies I expect to be a small minority ("It was fixed in
24.1", "I misunderstood and this is not actually a bug", etc.)

So I expect the result will be mostly be to annoy the bug reporters.

> The idea is to ask the bug-submitter's help.

Well, ok.

> I think this classification can be made automatically/heuristically
> by checking if the last message was from a developer.

I'm not optimistic that an automatic process can tell us much, but I
guess we'll see.

Re: Unanswered Emacs Problem Reports 40+ Months

[Christian Bryant]

On 10/25/2013 11:47 AM, Glenn Morris wrote:
> I imagine most responses will be of two kinds:
>
> 1) No reply. Then what?

Considering the bugs I will start with are the oldest there,
"no reply" to these bugs will simply produce a note in the
bug that a request for an update was made.  Better than
nothing, I think.

> 2) A slightly annoyed "yes, of course my wishlist/doc bug/whatever"
> still applies, didn't you read it/test it/try my patch?".
>
> The useful replies I expect to be a small minority ("It was fixed in
> 24.1", "I misunderstood and this is not actually a bug", etc.)

I will shoot a handy report every 50-100 bugs over to Stefan
with those who answered with a slightly annoyed "yes".  Taking
those in chunks and having new Emacs team members whittle them
down is both useful for them to better learn Emacs, and to
users who will see that bug maintenance does eventually happen.

> So I expect the result will be mostly be to annoy the bug reporters

I'm open to recommendations for the least annoying verbiage :-)

> I'm not optimistic that an automatic process can tell us much, but I
> guess we'll see.

I've performed tasks like this many times at work, for the same
reasons:  I saw a report where a specific application or library
not only dominated the bug report, but had the oldest bugs, too.
Maybe a year from now, or two or three years from now, some other
application can take that honor.

Cheers!

- CB

Re: Unanswered Emacs Problem Reports 40+ Months

[Glenn Morris]

Christian Bryant wrote:

> I will shoot a handy report every 50-100 bugs over to Stefan
> with those who answered with a slightly annoyed "yes".  Taking
> those in chunks and having new Emacs team members whittle them
                             ^^^^^^^^^^^^^^^^^^^^^^
I'm not aware that there are any such people with interest in dealing
with long-standing bug reports.

> I've performed tasks like this many times at work, for the same
> reasons:  I saw a report where a specific application or library
> not only dominated the bug report, but had the oldest bugs, too.
> Maybe a year from now, or two or three years from now, some other
> application can take that honor.

Up until a little over 40 months ago, no-one other than Emacs was using
debbugs.gnu.org, so the fact that almost all very old open bugs are
Emacs ones tells us nothing. Sources such as
http://debbugs.gnu.org/rrd/emacs.html are more informative.


BTW, there's no point querying anything tagged "confirmed" or "help"
(not that many things are), or "wontfix". Things with severity
"wishlist" or higher than "normal" are quite likely to still be
applicable (actually, I suppose, maybe, anything with severity !=
"normal"). Things tagged "moreinfo" are likely to ... need more
information.