How does the Emacs bug tracker work?

How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

If you go to:

http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs

You get:

Status

    * 381 Outstanding
    * 15 Resolved

but then if I hit "next 400", it then says:
    
Status

    * 378 Outstanding
    * 19 Resolved

and then "next 400" again, it says:

Status

    * 382 Outstanding
    * 2 Forwarded
    * 14 Resolved

And so on.  So when it's saying:

Showing results from bugs 800 - 1200 of 2669.

Does that really means that there are over 2000 unresolved bug reports
in the tracker?

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

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Hi,

First of all, there is a help-debbugs mailing list for these king of
questions. Second, it's not just the "Emacs" bug tracker any more! :)
See answers below:

Lars Magne Ingebrigtsen wrote:

> If you go to:
>
> http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs
>
> You get:
>
> Status
>
>     * 381 Outstanding
>     * 15 Resolved
>
> but then if I hit "next 400", it then says:

See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6533

> Does that really means that there are over 2000 unresolved bug reports
> in the tracker?

Yes.

http://debbugs.gnu.org/rrd/emacs.html

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6533

:-)

>> Does that really means that there are over 2000 unresolved bug reports
>> in the tracker?
>
> Yes.
>
> http://debbugs.gnu.org/rrd/emacs.html

Ouch.

Has there been a policy discussion here about how the bug tracker should
be handled?  Having witnessed these discussions before, there are
usually two sides of the argument:

1) All bugs, no matter how old, should be kept on the books until they
have been replicated and fixed, because, one day, somebody may take a
look at them and fix them.  Even though they're for really obscure
systems and the likelihood of that ever happening is small:

Viz:  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=244

2) Our bug-fixing manpower is limited, so we have to triage the bugs
hard, and discard² bug reports that are old, or refer to systems we don't
have access to, or are too nebulous, or are too "wouldn't it be nice if
we reimplemented everything in JavaScript"-ey.  That is, we should only
keep bug reports on the book that will realistically be handled by
someone within a reasonable time period.

Projects seem to start off as 1), and then shift to 2) after three
years, if they, at that point, can find some stooge actually willing to
sift through the 2.3k bug reports that are outstanding.  :-)

---
IV) "Discard" here means, "mark in a way that doesn't come up in the
default bug search/view".

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

Re: How does the Emacs bug tracker work?

[Dan Nicolaescu]

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

> Glenn Morris <rgm@gnu.org> writes:
>
>> See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6533
>
> :-)
>
>>> Does that really means that there are over 2000 unresolved bug reports
>>> in the tracker?
>>
>> Yes.
>>
>> http://debbugs.gnu.org/rrd/emacs.html
>
> Ouch.
>
> Has there been a policy discussion here about how the bug tracker should
> be handled?  Having witnessed these discussions before, there are
> usually two sides of the argument:
>
> 1) All bugs, no matter how old, should be kept on the books until they
> have been replicated and fixed, because, one day, somebody may take a
> look at them and fix them.  Even though they're for really obscure
> systems and the likelihood of that ever happening is small:
>
> Viz:  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=244

We do not support alpha*-dec-osf* anymore, so this particular bug
report can be closed.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Dan Nicolaescu <dann@gnu.org> writes:

> We do not support alpha*-dec-osf* anymore, so this particular bug
> report can be closed.

Right.

Then there's the oodles of misguided feature requests like (at random): 

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6891

which doesn't sound very useful, and is also incompatible with the
current return values, since (string-to-number "0x45" 16) today returns
0, so it should be dismissed instead of letting it linger on.

I wish we could have a Festival of Bug Triage, where each of us (how
many are there?  20?) pledge to close five bug reports per day.  That's
like a thousand in three weeks.  :-)

Then we could use the bug tracker to track bugs.

But, of course, it depends on what the policy for bug closure is...

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

Re: How does the Emacs bug tracker work?

[Julien Danjou]

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

On Thu, Jun 30 2011, Lars Magne Ingebrigtsen wrote:

> I wish we could have a Festival of Bug Triage, where each of us (how
> many are there?  20?) pledge to close five bug reports per day.  That's
> like a thousand in three weeks.  :-)

I'm in! :)

We could probably organize some bug squashing party, like Debian
sometimes does. Just plan a week-end where everybody squash or triage
bugs.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> We could probably organize some bug squashing party, like Debian
> sometimes does. Just plan a week-end where everybody squash or triage
> bugs.

Yeah, that'd be fun.  But we're kinda spread out, aren't we?  How many
of us are on each continent?  :-)

There's the

http://www.gnu.org/ghm/2011/paris/

in August...

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

Re: How does the Emacs bug tracker work?

[Bastien]

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

> Julien Danjou <julien@danjou.info> writes:
>
>> We could probably organize some bug squashing party, like Debian
>> sometimes does. Just plan a week-end where everybody squash or triage
>> bugs.
>
> Yeah, that'd be fun.  But we're kinda spread out, aren't we?  How many
> of us are on each continent?  :-)
>
> There's the
>
> http://www.gnu.org/ghm/2011/paris/

I'll be there, talking about org-mode -- so yeah, I can try to fix 
5 bugs this day for org-mode :)

-- 
 Bastien

Re: How does the Emacs bug tracker work?

[Julien Danjou]

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

On Thu, Jun 30 2011, Lars Magne Ingebrigtsen wrote:

> Yeah, that'd be fun.  But we're kinda spread out, aren't we?  How many
> of us are on each continent?  :-)
>
> There's the
>
> http://www.gnu.org/ghm/2011/paris/
>
> in August...

That could be a good idea, but that's not mandatory to have a physical
location IMHO: IRC can help too. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: How does the Emacs bug tracker work?

[Andreas Schwab]

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

> Then there's the oodles of misguided feature requests like (at random): 
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6891
>
> which doesn't sound very useful, and is also incompatible with the
> current return values, since (string-to-number "0x45" 16) today returns
> 0, so it should be dismissed instead of letting it linger on.

That could be solved by adding an optional argument.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: How does the Emacs bug tracker work?

[Deniz Dogan]

On 2011-06-30 11:09, Lars Magne Ingebrigtsen wrote:
> Dan Nicolaescu<dann@gnu.org>  writes:
>
>> We do not support alpha*-dec-osf* anymore, so this particular bug
>> report can be closed.
>
> Right.
>
> Then there's the oodles of misguided feature requests like (at random):
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6891
>
> which doesn't sound very useful, and is also incompatible with the
> current return values, since (string-to-number "0x45" 16) today returns
> 0, so it should be dismissed instead of letting it linger on.
>
> I wish we could have a Festival of Bug Triage, where each of us (how
> many are there?  20?) pledge to close five bug reports per day.  That's
> like a thousand in three weeks.  :-)
>
> Then we could use the bug tracker to track bugs.
>
> But, of course, it depends on what the policy for bug closure is...
>

The festival sounds like a great idea.  I just wish I had the knowledge 
to actually fix that many bugs.

Deniz

Re: How does the Emacs bug tracker work?

[Jason Rumney]

Deniz Dogan <deniz@dogan.se> writes:

>> I wish we could have a Festival of Bug Triage, where each of us (how
>> many are there?  20?) pledge to close five bug reports per day.  That's
>> like a thousand in three weeks.  :-)
>
> The festival sounds like a great idea.  I just wish I had the
> knowledge to actually fix that many bugs.

Note that the word used was CLOSE, not FIX.  If you can find 5 bug
reports per day that are no longer relevant, or perhaps never were, then
that would count too.

Re: How does the Emacs bug tracker work?

[Deniz Dogan]

On 2011-06-30 15:04, Jason Rumney wrote:
> Deniz Dogan<deniz@dogan.se>  writes:
>
>>> I wish we could have a Festival of Bug Triage, where each of us (how
>>> many are there?  20?) pledge to close five bug reports per day.  That's
>>> like a thousand in three weeks.  :-)
>>
>> The festival sounds like a great idea.  I just wish I had the
>> knowledge to actually fix that many bugs.
>
> Note that the word used was CLOSE, not FIX.  If you can find 5 bug
> reports per day that are no longer relevant, or perhaps never were, then
> that would count too.

Ah, well, then count me in.

Deniz

Re: How does the Emacs bug tracker work?

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 15:04, Jason Rumney <jasonr@gnu.org> wrote:

> Note that the word used was CLOSE, not FIX.  If you can find 5 bug
> reports per day that are no longer relevant, or perhaps never were, then
> that would count too.

What about Wontfix bugs? Shouldn't we close these?

    Juanma

Re: How does the Emacs bug tracker work?

[Julien Danjou]

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

On Thu, Jun 30 2011, Juanma Barranquero wrote:

> What about Wontfix bugs? Shouldn't we close these?

Usually they're good and valuable as documentation.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: How does the Emacs bug tracker work?

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 16:35, Julien Danjou <julien@danjou.info> wrote:

> Usually they're good and valuable as documentation.

Sometimes, perhaps. IMHO they're mostly clutter.

    Juanma

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

>> What about Wontfix bugs? Shouldn't we close these?
>
> Usually they're good and valuable as documentation.

Closed bugs are still there if you want to look at them.

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

Re: How does the Emacs bug tracker work?

[Stefan Monnier]

>>> What about Wontfix bugs? Shouldn't we close these?
>> Usually they're good and valuable as documentation.
> Closed bugs are still there if you want to look at them.

I see bugs as being in a few different states:
- untriaged: we got the report and nothing else happened.
- inprogress: there's been at least one reply to it.
- stuck: like inprogress, but without activity because of lack of info.
- forgotten: like stuck, except that rather than a lack of info, there's
  a lack of manpower.
- ready: there's a patch that fixes the problem and it looks like we
  just have to double-check and/or cleanup the patch.
- fixed: that's what we like.
- wontfix: we don't think it's a bug, or we don't like the requested
  feature and would hence oppose a patch if someone provides it.
- wishlist: not a bad idea, but noone cares enough to work on it.

These states map more or less to debbugs tags/severities:
- untriaged = "unclassified"
- inprogress = ???
- stuck = "moreinfo"
- forgotten = ???
- ready = "patch"
- fixed = "fixed" or "closed"
- wontfix = "notabug" or "wontfix"
- wishlist = "wishlist"

I don't really know what "closed" should mean in this respect and don't
really care as long as I can easily select which above states I want
to see.
And I don't understand why Debbugs has "wishlist" as a severity rather
than a tag (which prevents us from distinguishing important wishes from
minor ones).

The bad ones are "untriaged", "forgotten" and "ready", so we should come
up with a way to distinguish inprogress from untriaged, as well as a way
to mark the forgotten ones as well, so we can ask debbugs to show us
these ones.

I guess we could add "inprogress" and "forgotten" tags and then try to
be careful to add "inprogress" whenever we first reply to a bug report.
Then have some cron job check all the "inprogress" bugs and turn them
into "forgotten" after some pre-defined delay (at which point humans
way come and relabel it to "moreinfo" if the delay is not our fault).



        Stefan

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I see bugs as being in a few different states:
> - untriaged: we got the report and nothing else happened.
> - inprogress: there's been at least one reply to it.
> - stuck: like inprogress, but without activity because of lack of info.
> - forgotten: like stuck, except that rather than a lack of info, there's
>   a lack of manpower.
> - ready: there's a patch that fixes the problem and it looks like we
>   just have to double-check and/or cleanup the patch.
> - fixed: that's what we like.
> - wontfix: we don't think it's a bug, or we don't like the requested
>   feature and would hence oppose a patch if someone provides it.
> - wishlist: not a bad idea, but noone cares enough to work on it.

This is the actual metadata available on a bug:

(pp (debbugs-get-status 5458) (current-buffer))
(((source . "unknown")
  (done . "Lars Magne Ingebrigtsen <larsi@gnus.org>")
  (found_versions)
  (blocks)
  (date . 1264225022)
  (fixed)
  (fixed_versions)
  (mergedwith)
  (found)
  (unarchived)
  (blockedby)
  (keywords "moreinfo")
  (summary)
  (msgid . "<871vhh7588.fsf@jidanni.org>")
  (id . 5458)
  (forwarded)
  (severity . "normal")
  (owner)
  (log_modified . 1309402441)
  (location . "db-h")
  (subject . "Unknown charset: ansi_x3.4-1968")
  (originator . "jidanni@jidanni.org")
  (last_modified . 1309402441)
  (pending . "done")
  (affects)
  (archived)
  (tags "moreinfo")
  (fixed_date)
  (package "emacs" "gnus")
  (found_date)
  (bug_num . 5458)))

> These states map more or less to debbugs tags/severities:
> - untriaged = "unclassified"
> - inprogress = ???
> - stuck = "moreinfo"
> - forgotten = ???
> - ready = "patch"
> - fixed = "fixed" or "closed"
> - wontfix = "notabug" or "wontfix"
> - wishlist = "wishlist"
>
> I don't really know what "closed" should mean in this respect and don't
> really care as long as I can easily select which above states I want
> to see.

The relevant stuff we can search for are package, severity and tag (and
"archived", which is where I think "done" bugs up end after some days).

So "closed" is mainly a way to say "I probably don't normally want to
have these included in my searches".  So moving three year old
"wontfix"-es over to "closed" means taking less time searching for the
bugs you want to look at.

> The bad ones are "untriaged", "forgotten" and "ready", so we should come
> up with a way to distinguish inprogress from untriaged, as well as a way
> to mark the forgotten ones as well, so we can ask debbugs to show us
> these ones.

If `date' is the same as `log-modified', it means that nobody has
responded to the bug.  This can't be searched for, but can be
highlighted in the debbugs buffer.

> I guess we could add "inprogress" and "forgotten" tags and then try to
> be careful to add "inprogress" whenever we first reply to a bug report.
> Then have some cron job check all the "inprogress" bugs and turn them
> into "forgotten" after some pre-defined delay (at which point humans
> way come and relabel it to "moreinfo" if the delay is not our fault).

Adding these tags aren't really necessary if using the debbugs.el
interface.   An "inprogress" report is one that has gotten at least one
reply lately, and "forgotten" would be one where the reply is old.

So this can be controlled client-side.  If you don't consider 30 seconds
being too slow to get the complete list of bugs over to Emacs.

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

Re: How does the Emacs bug tracker work?

[Stefan Monnier]

> So "closed" is mainly a way to say "I probably don't normally want to
> have these included in my searches".  So moving three year old
> "wontfix"-es over to "closed" means taking less time searching for the
> bugs you want to look at.

No, in my experience what I want to include in my searches depends a lot
on what I'm doing.  If I'm searching for duplicates, I want to include
pretty much all previous bugs no matter what, and if I'm looking for
"bugs that need love" I don't want to include any wontfix, regardless of
their age.
IOW, I don't find the notion of "closed" to be useful.

>> The bad ones are "untriaged", "forgotten" and "ready", so we should come
>> up with a way to distinguish inprogress from untriaged, as well as a way
>> to mark the forgotten ones as well, so we can ask debbugs to show us
>> these ones.
> If `date' is the same as `log-modified', it means that nobody has
> responded to the bug.  This can't be searched for, but can be
> highlighted in the debbugs buffer.

Rather than highlight, I'd like to see them sorted first, but yes, that
should be good enough.

>> I guess we could add "inprogress" and "forgotten" tags and then try to
>> be careful to add "inprogress" whenever we first reply to a bug report.
>> Then have some cron job check all the "inprogress" bugs and turn them
>> into "forgotten" after some pre-defined delay (at which point humans
>> way come and relabel it to "moreinfo" if the delay is not our fault).
> Adding these tags aren't really necessary if using the debbugs.el
> interface.   An "inprogress" report is one that has gotten at least one
> reply lately,

OK.

> and "forgotten" would be one where the reply is old.

OK (except if it's marked "moreinfo", of course).

> So this can be controlled client-side.  If you don't consider 30 seconds
> being too slow to get the complete list of bugs over to Emacs.

Sounds fine,


        Stefan

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> No, in my experience what I want to include in my searches depends a lot
> on what I'm doing.  If I'm searching for duplicates, I want to include
> pretty much all previous bugs no matter what, and if I'm looking for
> "bugs that need love" I don't want to include any wontfix, regardless of
> their age.

When looking for duplicates, do you normally do text-based searches in
the web interface?  Apparently the SOAP interface doesn't allow
searching on the text...

> IOW, I don't find the notion of "closed" to be useful.

I think the normal understanding of "closed" is "a report we're not
going to do anything further with".  Which I think is a nice category to
have.

>> If `date' is the same as `log-modified', it means that nobody has
>> responded to the bug.  This can't be searched for, but can be
>> highlighted in the debbugs buffer.
>
> Rather than highlight, I'd like to see them sorted first, but yes, that
> should be good enough.

Sure; I can add sorting commands and stuff to the debbugs buffer.

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

Re: How does the Emacs bug tracker work?

[Michael Albinus]

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

>> IOW, I don't find the notion of "closed" to be useful.
>
> I think the normal understanding of "closed" is "a report we're not
> going to do anything further with".  Which I think is a nice category to
> have.

In Debbugs, this are archived reports. They are not taken into account
by ordinary searches; but you could enable that search by the :archive
keyword in debbugs-get-bugs.

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Chong Yidong]

Michael Albinus <michael.albinus@gmx.de> writes:

>>> IOW, I don't find the notion of "closed" to be useful.
>>
>> I think the normal understanding of "closed" is "a report we're not
>> going to do anything further with".
>
> In Debbugs, this are archived reports.

Closed bugs are archived after some time (and AFAICT closing a bug is
the only way to get it archived).

RE: How does the Emacs bug tracker work?

[Drew Adams]

> Closed bugs are archived after some time (and AFAICT closing a bug is
> the only way to get it archived).

I'm far from knowledgable about this, but my impression was that bugs get
automatically archived after a while, regardless of their status (e.g. closed).

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

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

> I'm far from knowledgable about this, but my impression was that bugs
> get automatically archived after a while, regardless of their status
> (e.g. closed).

If I query from the archive only, I get only messages marked as "done":

 8701 important,done       [jidanni@jidanni.org    ] Segmentation fault with j
 8702 important,done       [John ff                ] 23.1; Segmentation fault 
 8703 normal,done          [Bertram Felgenhauer    ] truncated unicode glyphs 
 8704 normal,done          [James Ahlborn          ] 23.2; nxml-mode function 
 8708 normal,done          [Alan Malloy            ] 24.0.50; up-list broken w
 8710 minor,done           [Leo                    ] 23.3.50; diff-refine-hunk
 8719 normal,done          [Paul Eggert            ] ccl: add some integer ove
 8721 normal,patch,done    [Dmitry Kurochkin       ] isearch does not handle l
 8722 normal,done          [Paul Eggert            ] dbusbind.c fixes for inte
 8731 normal,done          [Katsumi Yamaoka        ] 24.0.50; smtpmail-send-it
 8733 wishlist,patch,done  [Oliver Scholz          ] New Input Method for IPA 
 8735 minor,done           [bruce robertson        ] 23.2; shell mode mistaken

(Listing all severities from the archive took about a minute, so
apparently the "archive" isn't slower than the normal bugs.  I suspect
"archived" just means "isn't included in the default search", and the
only ones that get that treatment are apparently "done"-marked bugs that
are older than four weeks.)

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

Re: How does the Emacs bug tracker work?

[Glenn Morris]

> apparently the "archive" isn't slower than the normal bugs.  I suspect
> "archived" just means "isn't included in the default search", and the
> only ones that get that treatment are apparently "done"-marked bugs that
> are older than four weeks.)

admin/notes/bugtracker:

    ** How does archiving work?
    You can still send mail to a bug after it is closed.  After 28 days with
    no activity, the bug is archived, at which point no more changes can
    be made.  If you try to send mail to the bug after that (or merge with
    it), it will be rejected.  To make any changes, you must unarchive it
    first:

    unarchive 123

    The bug will be re-archived after the next 28 day period of no activity.

Re: How does the Emacs bug tracker work?

[Michael Albinus]

Chong Yidong <cyd@stupidchicken.com> writes:

> Michael Albinus <michael.albinus@gmx.de> writes:
>
>>>> IOW, I don't find the notion of "closed" to be useful.
>>>
>>> I think the normal understanding of "closed" is "a report we're not
>>> going to do anything further with".
>>
>> In Debbugs, this are archived reports.
>
> Closed bugs are archived after some time (and AFAICT closing a bug is
> the only way to get it archived).

Yes. Debbugs says:

"If a report is closed and receives no more mail for one month, it is
 archived."

When I have regarded "archived" as kind of "closed", it was from a
conceptual pov. The bug isn't visible anymore, unless you bring it back.

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Richard Stallman]

Isn't marking a bug "wontfix" a way of closing it?


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: How does the Emacs bug tracker work?

[Chong Yidong]

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

> Then there's the oodles of misguided feature requests like (at random):
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6891
>
> which doesn't sound very useful, and is also incompatible with the
> current return values, since (string-to-number "0x45" 16) today
> returns 0, so it should be dismissed instead of letting it linger on.

Most such bugs are already marked wishlist; unless the request is truly
outlandish, letting them "linger on" is not a big deal, since they are
easy to exclude in searches.

Similarly, we have lots of bugs tagged unreproducible and/or wontfix.
We haven't been closing these, but if that bothers people, we could
institute a policy of closing such bugs if there is no traffic after,
say, a year.  I don't care, personally.

As for the rest of the old bugs, many are "long tail" issues that are
difficult and/or time-consuming to debug and fix.  Hopefully, we will be
able to make a dent in this over the course of the pretest.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

>> Then there's the oodles of misguided feature requests like (at random):
>>
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6891
>>
>> which doesn't sound very useful, and is also incompatible with the
>> current return values, since (string-to-number "0x45" 16) today
>> returns 0, so it should be dismissed instead of letting it linger on.
>
> Most such bugs are already marked wishlist; unless the request is truly
> outlandish, letting them "linger on" is not a big deal, since they are
> easy to exclude in searches.

Right;

http://debbugs.gnu.org/cgi/pkgreport.cgi?exclude=severity%3Awishlist;package=emacs

will exclude the wishlist items from the list of whatever it's decided
to show here.  However, the search interface doesn't seem to offer any
way to list all the open bugs, since there are so many unclosed bugs
there, and it only allows searching amongst 400 reports at a time?

I think the wishlist item in question is pretty typical -- it's not
outlandish, but (in my opinion) the utility here is pretty minuscule.  

Adding (string-to-number "#B11101" 'guess) would be possible, but
... why?  Especially since it's a C-level function.

> Similarly, we have lots of bugs tagged unreproducible and/or wontfix.
> We haven't been closing these, but if that bothers people, we could
> institute a policy of closing such bugs if there is no traffic after,
> say, a year.  I don't care, personally.

Why not close immediately?  (Especially wontfix.)  Bugs can be reopened
if closed prematurely.

> As for the rest of the old bugs, many are "long tail" issues that are
> difficult and/or time-consuming to debug and fix.  Hopefully, we will be
> able to make a dent in this over the course of the pretest.

I hope so, too, but I think without a policy change in how bug triage is
done, it'll be rather demotivating.  Seeing the number of outstanding
bug reports shrink is a motivating factor in itself.  :-)

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

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> However, the search interface doesn't seem to offer any way to list
> all the open bugs, since there are so many unclosed bugs there, and it
> only allows searching amongst 400 reports at a time?

This is an argument for improving the search.
I'd love it if someone would fix #6533 for me.

You can use the static index (linked from the front page) to list all
open reports:

http://debbugs.gnu.org/db/pa/lemacs.html

Re: How does the Emacs bug tracker work?

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> This is an argument for improving the search.
> I'd love it if someone would fix #6533 for me.

debbugs.el does not suffer from this limitation:

(length (debbugs-get-bugs :severity "normal"))
 => 1860

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Michael Albinus wrote:

> debbugs.el does not suffer from this limitation:
>
> (length (debbugs-get-bugs :severity "normal"))
>  => 1860

It does, however, have pretty much the same impact on the server, in
terms of using quite a lot of memory, which is why I put the 400 bugs
limitation into the web-based search. So I think this could cause
problems if a lot of people start using it.

Could you consider putting in a similar kind of limit to the
number of bugs the `debbugs-emacs' command will fetch?

Re: How does the Emacs bug tracker work?

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

Hi Glenn,

>> debbugs.el does not suffer from this limitation:
>>
>> (length (debbugs-get-bugs :severity "normal"))
>>  => 1860
>
> It does, however, have pretty much the same impact on the server, in
> terms of using quite a lot of memory, which is why I put the 400 bugs
> limitation into the web-based search. So I think this could cause
> problems if a lot of people start using it.

What does cause the load? debbugs-get-bugs or debbugs-get-status? I
suspect the latter one, which could carry an arbitrary number of
bugnumbers.

> Could you consider putting in a similar kind of limit to the
> number of bugs the `debbugs-emacs' command will fetch?

I believe, this shall be implemented in the frontend Lars is working
on. debbugs-get-bugs returns the bug numbers, and before calling
debbugs-get-status, the frontend could ask (like in gnus):

  How many articles from gmane.emacs.devel (available 140599, default 200):

Btw, for debian.org such a restriction would be even more important:

  (let ((debbugs-port "debian.org"))
    (debbugs-newest-bugs 1))
  => (632453)

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I believe, this shall be implemented in the frontend Lars is working
> on. debbugs-get-bugs returns the bug numbers, and before calling
> debbugs-get-status, the frontend could ask (like in gnus):
>
>   How many articles from gmane.emacs.devel (available 140599, default 200):

Yes, I could add something like that.  

> Btw, for debian.org such a restriction would be even more important:
>
>   (let ((debbugs-port "debian.org"))
>     (debbugs-newest-bugs 1))
>   => (632453)

Yeah, but there's only

  (let ((debbugs-port "debian.org"))
    (length (debbugs-get-bugs :severity "normal")))
  => 33394

33K open normal bug reports.  :-)
  
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: How does the Emacs bug tracker work?

[Michael Albinus]

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

>> I believe, this shall be implemented in the frontend Lars is working
>> on. debbugs-get-bugs returns the bug numbers, and before calling
>> debbugs-get-status, the frontend could ask (like in gnus):
>>
>>   How many articles from gmane.emacs.devel (available 140599, default 200):
>
> Yes, I could add something like that.  

I've just done this. However, it might confuse people that less reports
are visible than said, because the "done" reports are filtered out.

Furthermore, it shows just the *last* xxx reports. For more convenience,
we might introduce a pager (widget at the end of buffer), which shows
the next xxx reports, again.

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I've just done this. However, it might confuse people that less reports
> are visible than said, because the "done" reports are filtered out.

Yes, I'm wondering whether to include the "done" reports by default.  (I
mean, the "done" "unarchived" reports.)

It's nice to see the recently closed reports, I find.

> Furthermore, it shows just the *last* xxx reports. For more convenience,
> we might introduce a pager (widget at the end of buffer), which shows
> the next xxx reports, again.

Yes, that makes sense.

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

Re: How does the Emacs bug tracker work?

[Michael Albinus]

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

>> Furthermore, it shows just the *last* xxx reports. For more convenience,
>> we might introduce a pager (widget at the end of buffer), which shows
>> the next xxx reports, again.
>
> Yes, that makes sense.

OK, I'll try it.

Best regards, Michael

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Michael Albinus wrote:

> Furthermore, it shows just the *last* xxx reports. For more convenience,
> we might introduce a pager (widget at the end of buffer), which shows
> the next xxx reports, again.

That's the kind of thing I was thinking of. Eg see

http://debbugs.gnu.org/emacs

Showing 400 of 2522 bugs
Page: 1 2 3 4 5 6 7

Re: How does the Emacs bug tracker work?

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> Michael Albinus wrote:
>
>> Furthermore, it shows just the *last* xxx reports. For more
>> convenience, we might introduce a pager (widget at the end of
>> buffer), which shows the next xxx reports, again.
>
> That's the kind of thing I was thinking of. Eg see
>
> http://debbugs.gnu.org/emacs
>
> Showing 400 of 2522 bugs
> Page: 1 2 3 4 5 6 7

I just noticed: you must have fixed the ordering of the pages.  They're
now in chronological sequence, whereas IIRC it used to be ordered in
some other way that I could never figure out.  Thanks!

Re: How does the Emacs bug tracker work?

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> That's the kind of thing I was thinking of. Eg see
>
> http://debbugs.gnu.org/emacs
>
> Showing 400 of 2522 bugs
> Page: 1 2 3 4 5 6 7

I've added this.

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Michael Albinus wrote:

> What does cause the load? debbugs-get-bugs or debbugs-get-status? I
> suspect the latter one, which could carry an arbitrary number of
> bugnumbers.

I think you are right; at least the former doesn't have much of an
effect on the load.

> debbugs-get-status, the frontend could ask (like in gnus):
>
>   How many articles from gmane.emacs.devel (available 140599, default 200):

OK, except there should be a hard-coded upper limit on the number you
can fetch at any one time (really this should be implemented on the
server I guess, argh, but it would be great if the client could
implement it). Say 500?

Re: How does the Emacs bug tracker work?

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> OK, except there should be a hard-coded upper limit on the number you
> can fetch at any one time (really this should be implemented on the
> server I guess, argh, but it would be great if the client could
> implement it). Say 500?

I've changed that default value. It's hard coded now; if needed we could
make it a defcustom.

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Michael Albinus <michael.albinus@gmx.de> writes:

> I've changed that default value. It's hard coded now; if needed we could
> make it a defcustom.

I think 500 is way too low.  Fetching 500 bugs (via Emacs) takes about
the same time as displaying one reload of the debbugs web page.

And I suspect that will be accessed 1000x more often than the Emacs
interface (by web bots :-), so the limit from the Emacs interface should
be at least 2K.

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

Re: How does the Emacs bug tracker work?

[Michael Albinus]

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

>> I've changed that default value. It's hard coded now; if needed we could
>> make it a defcustom.
>
> I think 500 is way too low.  Fetching 500 bugs (via Emacs) takes about
> the same time as displaying one reload of the debbugs web page.
>
> And I suspect that will be accessed 1000x more often than the Emacs
> interface (by web bots :-), so the limit from the Emacs interface should
> be at least 2K.

I have no serious meaning about. Let's Glenn observe it for a while, and
maybe we could tune.

The Lars-bot works interactively, and he is prompted for another value :-)

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> I think 500 is way too low.  Fetching 500 bugs (via Emacs) takes about
> the same time as displaying one reload of the debbugs web page.

It's not that inconvenient to looks at 500 reports at a time is it?
This gives you just over 3 pages to look at, for the current open normal
bugs, after ~ 3 years of tracking bugs.

> And I suspect that will be accessed 1000x more often than the Emacs
> interface (by web bots :-),

robots.txt forbids them. :)

> so the limit from the Emacs interface should be at least 2K.

Fetching 500 bugs uses ~ 10% of the real memory on the server.
Maybe I'm overly cautious, but that seems about the right limit to me.
The machine doesn't have much memory, and a lot is used up running
spamassassin, mailman, etc.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> It's not that inconvenient to looks at 500 reports at a time is it?
> This gives you just over 3 pages to look at, for the current open normal
> bugs, after ~ 3 years of tracking bugs.

I'm just neurotically pleased with being able to see it all at once, and
being able to sort stuff in the buffer.  :-)

> Fetching 500 bugs uses ~ 10% of the real memory on the server.

Wow.

> Maybe I'm overly cautious, but that seems about the right limit to me.
> The machine doesn't have much memory, and a lot is used up running
> spamassassin, mailman, etc.

Yeah, I didn't know it was that memory-intensive.

Is there any way to fix that?  :-)

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

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Is there any way to fix that?  :-)

The machine only has 500MB to start with is one thing.
Beyond that, I've never looked at the soap stuff.
Source code is available via http://wiki.debian.org/Teams/Debbugs ,
if anyone wants to look into it.

We started from http://bzr.donarmstrong.com/debbugs/branches/emacsbugs/
but have diverged a little bit here and there. Sorry we don't have a bzr
for our version (I keep meaning to make one), it's all in-place hacks.
Nothing truly major though.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

>> And I suspect that will be accessed 1000x more often than the Emacs
>> interface (by web bots :-),
>
> robots.txt forbids them. :)

Which reminds me -- searching for Emacs bugs on Google only seems to
give me the static (archived) bug reports.  And this is presumably
because the machine disallows searching for the non-archived (newer) bug
reports?

I think it would be nice if people were able to use the search engines
to find previous bug reports.  :-)

Is there any plans to upgrade the debbugs.gnu.org machine so that it
could allow search engines back?  If it's a 500MB machine now, it sounds
like it might be slightly (ahem) old?

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

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Which reminds me -- searching for Emacs bugs on Google only seems to
> give me the static (archived) bug reports. 
>
> And this is presumably because the machine disallows searching for the
> non-archived (newer) bug reports?

I don't know what you mean by "(archived)". The static pages list the
*non*-archived reports, and are updated daily. It's the older, archived
reports that are not included.

> I think it would be nice if people were able to use the search engines
> to find previous bug reports.  :-)

They can:

1) search the static pages via their search engine of choice. These all
contain big links (in red) to the dynamic pages.

2) search the bug mailing list archives using their search engine of
choice, or the supplied lists.gnu.org search

3) use the normal debbugs search

4) use the full-text debbugs search

> Is there any plans to upgrade the debbugs.gnu.org machine so that it
> could allow search engines back?  If it's a 500MB machine now, it sounds
> like it might be slightly (ahem) old?

Not AFAIK (to both questions). It's a virtual machine that has a slice
of some large-ish, modern-ish, machine (I guess). It seems quite capable
of doing what it needs to do, IMO. I don't see a need to allow search
engines to run cgi queries on it.

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> I don't know what you mean by "(archived)". The static pages list the
> *non*-archived reports, and are updated daily. It's the older, archived
> reports that are not included.

Oh, OK, I misunderstood.  Then things should be fine.

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

Re: How does the Emacs bug tracker work?

[Glenn Morris]

Glenn Morris wrote:

> I'd love it if someone would fix #6533 for me.

I fixed it myself.

Re: How does the Emacs bug tracker work?

[Richard Stallman]

Should someone look through the wishlist and add items to etc/TODO?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: How does the Emacs bug tracker work?

[Juanma Barranquero]

On Thu, Jun 30, 2011 at 17:15, Chong Yidong <cyd@stupidchicken.com> wrote:

> Similarly, we have lots of bugs tagged unreproducible and/or wontfix.
> We haven't been closing these, but if that bothers people, we could
> institute a policy of closing such bugs if there is no traffic after,
> say, a year.

Yes, please. I agreethat Wontfixes are perhaps valuables as
documentation, but closing them will not affect that.

As for Unreproducibles, if no additional information has been
forthcoming in a year, its likely that noone is really interested in
pursuing the issue (or perhaps it was fixed somehow and nobody noticed
or reported it).

> As for the rest of the old bugs, many are "long tail" issues that are
> difficult and/or time-consuming to debug and fix.

Yes. There are lots of bugs where there's a consensus that the problem
is real (though sometimes not what the OP reported), and then the
discussion sort of dwindles.

    Juanma

Re: How does the Emacs bug tracker work?

[Stephen J. Turnbull]

Juanma Barranquero writes:
 > On Thu, Jun 30, 2011 at 17:15, Chong Yidong <cyd@stupidchicken.com> wrote:
 > 
 > > Similarly, we have lots of bugs tagged unreproducible and/or wontfix.
 > > We haven't been closing these, but if that bothers people, we could
 > > institute a policy of closing such bugs if there is no traffic after,
 > > say, a year.
 > 
 > Yes, please. I agreethat Wontfixes are perhaps valuables as
 > documentation, but closing them will not affect that.

Actually, it can.  The problem is that when you do a specific search
for the-bug-you-are-about-to-report, most trackers will apply the "not
closed" filter.  In that case there will be a strong tendency to
increase the number of dupes.

I think this is one case where users need one interface that normally
presents WontFix bugs to them, and maintainers need that interface
(for reporting and perhaps for trolling for WontFixes that they want
to fix :-) plus another one that tells them about only active bugs.

Does debbugs allow that distinction?

Or perhaps a DWIM interface that looks for WontFixes as well as open
bugs if the query contains sufficient specificity (the definition
would need to be tuned, though).

 > As for Unreproducibles, if no additional information has been
 > forthcoming in a year, its likely that noone is really interested in
 > pursuing the issue (or perhaps it was fixed somehow and nobody noticed
 > or reported it).

Agreed, these don't have the same problem.

 > > As for the rest of the old bugs, many are "long tail" issues that are
 > > difficult and/or time-consuming to debug and fix.
 > 
 > Yes. There are lots of bugs where there's a consensus that the problem
 > is real (though sometimes not what the OP reported), and then the
 > discussion sort of dwindles.

If they're really that hard, and there's a UI that shows WontFix to
users searching for a specific issue and hides them from developers,
you could Important/WontFix/Close the hardest ones.  Emacs has a very
disciplined group of core workers, and perhaps some would volunteer to
regularly troll for WontFix+Important or some such anomolous-looking
pattern, and reopen "interesting" ones.

Alternatively to all of the above, Roundup has a contributed script
that regularly (by default, each week) sends a bug summary to the
developers list.  I don't know how many Emacs developers would use
such a thing (it's a matter of taste, of course), but I know that
several people on the python-dev list use theirs -- it's visible in
their posts about "isn't it time to do something about this bug?" etc.

Note that some of the suggestions above are somewhat inconsistent with
each other and implementing all of them would result in excessive
complexity in the interface.

Re: How does the Emacs bug tracker work?

[Juanma Barranquero]

On Fri, Jul 1, 2011 at 03:03, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Actually, it can.  The problem is that when you do a specific search
> for the-bug-you-are-about-to-report, most trackers will apply the "not
> closed" filter.  In that case there will be a strong tendency to
> increase the number of dupes.

A strong tendency, with little impact IMHO because it seems that most
people does a very cursory "specific search for
the-bug-you-are-about-to-report". At least that's my feeling...

> Alternatively to all of the above, Roundup has a contributed script
> that regularly (by default, each week) sends a bug summary to the
> developers list.  I don't know how many Emacs developers would use
> such a thing (it's a matter of taste, of course), but I know that
> several people on the python-dev list use theirs -- it's visible in
> their posts about "isn't it time to do something about this bug?" etc.

I would really like something that brought to attention stagnated bug reports.

    Juanma

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

> I would really like something that brought to attention stagnated bug
> reports.

There are 2600 bug reports, of which at around 1500 (I think) are
"normal" and stagnant.  So sending reports about this stuff until it's
been cleaned up is pretty useless, I think.

I've started doing my part.  5 closed reports per day or bust!  :-)

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

Re: How does the Emacs bug tracker work?

[Juanma Barranquero]

On Fri, Jul 1, 2011 at 13:48, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> There are 2600 bug reports, of which at around 1500 (I think) are
> "normal" and stagnant.  So sending reports about this stuff until it's
> been cleaned up is pretty useless, I think.

Well, perhaps not all at once :-)

> I've started doing my part.  5 closed reports per day or bust!  :-)

I tend to lose my faith whenever I find a bug where knowledgeable
people discusses the issue for a while and then... just silence.

    Juanma

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Juanma Barranquero <lekktu@gmail.com> writes:

>> I've started doing my part.  5 closed reports per day or bust!  :-)
>
> I tend to lose my faith whenever I find a bug where knowledgeable
> people discusses the issue for a while and then... just silence.

Yeah.  There are so many issues where if you do it one way, it'll make
that work but not that, and in a different way, it'll make that other
thing work but not the first thing.

Those kinds of things remain open forever until somebody says "well,
we'll have to live with it" and closes the report.

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

Re: How does the Emacs bug tracker work?

[Stephen J. Turnbull]

Juanma Barranquero writes:

 > A strong tendency, with little impact IMHO because it seems that most
 > people does a very cursory "specific search for
 > the-bug-you-are-about-to-report". At least that's my feeling...

This is true (but debbugs.el looks like it will help a lot!)  However,
my (limited) experience with our Roundup, and (vicarious) experience
with Python's suggests that improvements in search technology can
dramatically increase the rate of people searching.

 > I would really like something that brought to attention stagnated
 > bug reports.

Well, IIRC you've got about 1500 of them; why not just
(debbugs-get-bug (random 2600))? <wink/>

Re: How does the Emacs bug tracker work?

[Juanma Barranquero]

On Fri, Jul 1, 2011 at 14:51, Stephen J. Turnbull <stephen@xemacs.org> wrote:

> Well, IIRC you've got about 1500 of them; why not just
> (debbugs-get-bug (random 2600))? <wink/>

Not just *my* attention ;-)

    Juanma

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> This is true (but debbugs.el looks like it will help a lot!)  However,
> my (limited) experience with our Roundup, and (vicarious) experience
> with Python's suggests that improvements in search technology can
> dramatically increase the rate of people searching.

Yeah.  The debbugs web interface does have search capabilities, but it's
somewhat limited.  Is debbugs being actively maintained?

It'd be awesome if one could search for stuff from debbugs.el, though.
Popping up a summary buffer with all the bug reports (and replies) for a
search term would be very nice.

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

Re: How does the Emacs bug tracker work?

[Michael Albinus]

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

> Yeah.  The debbugs web interface does have search capabilities, but it's
> somewhat limited.  Is debbugs being actively maintained?

Yes. Principal maintainer is Don Armstrong <don@debian.org>. Mailing
list is debian-debbugs@lists.debian.org

debbugs' sources can be download as Debian package "debbugs".

> It'd be awesome if one could search for stuff from debbugs.el, though.

Yes, that's also on my wishlist. The SOAP interface shall be extended to
support search request to the Hyper Estraier search engine on the
debbugs server(s).

> Popping up a summary buffer with all the bug reports (and replies) for a
> search term would be very nice.

This I would let for you :-)

Best regards, Michael.

Re: How does the Emacs bug tracker work?

[Julien Danjou]

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

On Fri, Jul 01 2011, Lars Magne Ingebrigtsen wrote:

> Yeah.  The debbugs web interface does have search capabilities, but it's
> somewhat limited.  Is debbugs being actively maintained?

http://lists.debian.org/debian-debbugs/2011/07/msg00000.html

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: How does the Emacs bug tracker work?

[Lars Magne Ingebrigtsen]

Julien Danjou <julien@danjou.info> writes:

> http://lists.debian.org/debian-debbugs/2011/07/msg00000.html

"Dead debbugs hackers (and lurkers),"

Apparently I wasn't the only one who had doubts!  :-)

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