debbugs.el revisited

debbugs.el revisited

[Lars Magne Ingebrigtsen]

I found the debbugs web interface too annoying to work with, so I
grabbed a copy of debbugs.el and started hacking.

I've now got it to a state where if you search for "important", you get
a buffer like this:

 2056 important [Ian Eure               ] 23.0.60; Enabling flyspell degrades p
 2503 important [Leo                    ] 23.0.91; poor performance of flyspell
 2639 important [Plan Kalkul            ] scrolling slow with word-wrap and fly
 3347 important [YAMAMOTO Mitsuharu     ] 23.0.93; unnecessary display updates 
 3944 important [Tommi Raulahti         ] GNU Emacs and Digital Unix (OSF1) 5.1
 4273 important [David Reitter          ] flyspell-region / accept-process-outp
 5133 important [Steve Revilak          ] 23.1; ispell-buffer with LaTeX file V
 5786 important [Daniel Colascione      ] new cc-mode <>-matching barfs in comp
 6350 important [Thierry Volpiatto      ] 24.0.50; C-d in ielm doesn't work as 
 6352 important [Dmitri Paduchikh       ] 24.0.50; process-send-eof doesn't wor
 6401 important [Sigve Berge Hofland    ] Failure in loading charset map: JISX0
 6649 important [enami tsugutomo        ] 24.0.50; C-g doesn't work since emacs
 7643 important [Chong Yidong           ] Build failure for SGI IRIX MIPS
 7762 important [wanziforever@gmail.com ] fail to build and install emacs on so
 8915 important [David Aspinall         ] 23.3; Repeatable segmentation fault, 

and you can RET each line to open an ephemeral Gnus group to read the
thread.  And Gnus will keep track of what messages in there you've read,
etc, of course, via gnus-dup.

However, the SOAP interface requires that you do one request per bug
report to get the bug metadata.  So to list all the "normal" level bugs,
that would be 1600 requests, which is just too slow to use.

Which I think is more or less where we ended up last time.

Has anybody done any more work in this area?  I mean, making the debbugs
server side expose a more sensible interface?

Meanwhile, while this may not be totally usable for normal usage, it's
possible to use this while doing bug triage by saying that you want, for
instance, message 100-200 of the "normal" level bugs.

I'm also adding a Gnus minor mode to do the normal triage stuff -- that
is, if you're in an ephemeral group looking at bug report 7643, and
you've determined that it's a wishlist item, `c wishTAB' will send off a
message to control@debbugs.gnu.org saying "tags 7643 wishlist", and so
on.  Which should speed stuff up considerably when doing a triage.

debbugs.el currently lives in GNU ELPA.  Can I check it into the Emacs
sources for easier continued development and usage?

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

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

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

> However, the SOAP interface requires that you do one request per bug
> report to get the bug metadata.  So to list all the "normal" level bugs,
> that would be 1600 requests, which is just too slow to use.

That turned out to be a giant misreading on my part.  I can request all
the data in one fell swoop.

Listing all the 1600 "normal" bug reports takes 25 seconds.

I'm mostly done now with the major bits, and it feels quite usable.

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

Re: debbugs.el revisited

[Michael Albinus]

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

> However, the SOAP interface requires that you do one request per bug
> report to get the bug metadata.  So to list all the "normal" level bugs,
> that would be 1600 requests, which is just too slow to use.

That's a misunderstanding. You can retrieve bug metadata for a list of
bug numbers at once.

Best regards, Michael.

Re: debbugs.el revisited

[Chong Yidong]

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

> debbugs.el currently lives in GNU ELPA.  Can I check it into the Emacs
> sources for easier continued development and usage?

Please work in the GNU ELPA repository.

I'm working on some changes that should make it more convenient to keep
stuff in that repository up to date for developers.

> the SOAP interface requires that you do one request per bug report to
> get the bug metadata.  So to list all the "normal" level bugs, that
> would be 1600 requests, which is just too slow to use.

According to the Debbugs SOAP interface documentation at

http://wiki.debian.org/DebbugsSoapInterface

the get_status method accepts multiple bug numbers, so it should only be
necessary to make one request.

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

>> debbugs.el currently lives in GNU ELPA.  Can I check it into the Emacs
>> sources for easier continued development and usage?
>
> Please work in the GNU ELPA repository.

I think the debbugs.el interface is very usable now, and should be used
by both developers and users to check and track bug reports.  It's
certainly more convenient than the web interface.

So I think it should go into Emacs.  But you're the boss.

> According to the Debbugs SOAP interface documentation at
>
> http://wiki.debian.org/DebbugsSoapInterface
>
> the get_status method accepts multiple bug numbers, so it should only be
> necessary to make one request.

Yeah, I found that out after a while.

Is there any particular reason emails sometimes take hours to get posted
to the mailing list?  It's kinda odd...

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

Re: debbugs.el revisited

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> Is there any particular reason emails sometimes take hours to get posted
> to the mailing list?

AFAIK it's a general lists.gnu.org thing (this list seems to have a
similar issue today).

It was fast for a brief time after it moved to its new server, but
lately it seems to be slow again.

If you've got a documented case, you can ask sysadmin@gnu.

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> It was fast for a brief time after it moved to its new server, but
> lately it seems to be slow again.
>
> If you've got a documented case, you can ask sysadmin@gnu.

For instance this one.

Message-ID: <m3boxftd6j.fsf@quimbies.gnus.org>

[...]

Original-Received: from lists.gnu.org ([140.186.70.17])
	by lo.gmane.org with esmtp (Exim 4.69)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1QcN8j-00046m-Mw
	for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2011 21:43:05 +0200
Original-Received: from localhost ([::1]:60487 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	id 1QcN8i-000440-CW
	for ged-emacs-devel@m.gmane.org; Thu, 30 Jun 2011 15:43:04 -0400
Original-Received: from eggs.gnu.org ([140.186.70.92]:40891)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1QcLUk-0000Fh-SN
	for emacs-devel@gnu.org; Thu, 30 Jun 2011 13:57:44 -0400

All these time zones makes it a bit more difficult to read, but
eggs.gnu.org got this at 13:57:44 -0400, and lists.gnu.org got or sent
it at 15:43:04 -0400.  Which is a delay of almost two hours...

Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1QcLUi-000194-1K
	for emacs-devel@gnu.org; Thu, 30 Jun 2011 13:57:42 -0400
Original-Received: from lo.gmane.org ([80.91.229.12]:39148)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1QcLUh-00018r-Bw
	for emacs-devel@gnu.org; Thu, 30 Jun 2011 13:57:39 -0400
Original-Received: from list by lo.gmane.org with local (Exim 4.69)
	(envelope-from <ged-emacs-devel@m.gmane.org>) id 1QcLUg-0002FF-6e
	for emacs-devel@gnu.org; Thu, 30 Jun 2011 19:57:38 +0200


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

Re: debbugs.el revisited

[Stefan Monnier]

> I think the debbugs.el interface is very usable now, and should be used
> by both developers and users to check and track bug reports.  It's
> certainly more convenient than the web interface.

I agree with Chong, it should stay in GNU ELPA for now at least.
E.g. that lets you hack on it regardless of Emacs's feature freeze.


        Stefan

Re: debbugs.el revisited

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Jun 2011 22:28:23 -0400
> 
> > I think the debbugs.el interface is very usable now, and should be used
> > by both developers and users to check and track bug reports.  It's
> > certainly more convenient than the web interface.
> 
> I agree with Chong, it should stay in GNU ELPA for now at least.

Why not in admin/ ?

Re: debbugs.el revisited

[Štěpán Němec]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Date: Thu, 30 Jun 2011 22:28:23 -0400
>> 
>> > I think the debbugs.el interface is very usable now, and should be used
>> > by both developers and users to check and track bug reports.  It's
>> > certainly more convenient than the web interface.
>> 
>> I agree with Chong, it should stay in GNU ELPA for now at least.
>
> Why not in admin/ ?

Why not in the core, and even suggest its use in the `report-emacs-bug'
template (it could even search for the subject line automatically or
something like that)? It does look like a much superior way to check for
duplicates etc. than using the web interface.

  Štěpán

Re: debbugs.el revisited

[Julien Danjou]

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

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

> I think the debbugs.el interface is very usable now, and should be used
> by both developers and users to check and track bug reports.  It's
> certainly more convenient than the web interface.

I support Lars on this. :)

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

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

Re: debbugs.el revisited

[Michael Albinus]

Julien Danjou <julien@danjou.info> writes:

>> I think the debbugs.el interface is very usable now, and should be used
>> by both developers and users to check and track bug reports.  It's
>> certainly more convenient than the web interface.
>
> I support Lars on this. :)

1+, obviously.

Best regards, Michael.

Re: debbugs.el revisited

[Glenn Morris]

BTW, I suggest making debbugs-send-control-message prompt for and pass
an optional version number when closing bugs. This information is very
useful, IMO.

Also I don't think adding the "fixed" tags at the same time as you close
is of any use. The help says:

  fixed
      This bug is fixed or worked around, but there's still an issue that
      needs to be resolved

ie fixed is just a weaker version of closed. (It seems like a fairly
useless tag altogether to me.)

If someone reopens a bug later on, do they also need to remember to
remove the "fixed" tag?


Other commands you might want to add:
unarchive
reopen
merge
forcemerge

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> BTW, I suggest making debbugs-send-control-message prompt for and pass
> an optional version number when closing bugs. This information is very
> useful, IMO.

The version number is the version number the fix has been applied to?
Then perhaps it could just default to sending over

emacs-version
=> "24.0.50.6"

if the user doesn't override it?

What does the control message for the version number in debbugs look
like?
    
> Also I don't think adding the "fixed" tags at the same time as you close
> is of any use. The help says:
>
>   fixed
>       This bug is fixed or worked around, but there's still an issue that
>       needs to be resolved
>
> ie fixed is just a weaker version of closed. (It seems like a fairly
> useless tag altogether to me.)

Oh, I thought we wanted to differentiate between (for instance)
"notabug,closed" and "fixed,closed"...

> If someone reopens a bug later on, do they also need to remember to
> remove the "fixed" tag?

Doesn't the same apply to other tags like "notabug"?

> Other commands you might want to add:
> unarchive
> reopen
> merge
> forcemerge

Ok; done.

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

Re: debbugs.el revisited

[Michael Albinus]

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

>> BTW, I suggest making debbugs-send-control-message prompt for and pass
>> an optional version number when closing bugs. This information is very
>> useful, IMO.
>
> The version number is the version number the fix has been applied to?
> Then perhaps it could just default to sending over
>
> emacs-version
> => "24.0.50.6"
>
> if the user doesn't override it?

I believe, "24.0.50" would be better in this case. For searching purposes.

Best regards, Michael.

Re: debbugs.el revisited

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> The version number is the version number the fix has been applied to?
> Then perhaps it could just default to sending over
>
> emacs-version
> => "24.0.50.6"
>
> if the user doesn't override it?

I think that's a bad idea. The right number to use in that case would be
"24.1", ie the first _release_ in which something is fixed. "24.0.50.6",
or even "24.0.50" is a meaningless version number.
Obviously you could automatically deduce "24.1" and use that instead,
but I think passing a version number by default is not a good idea.
Just give the option to specify a version number when the user thinks
it's appropriate, and otherwise don't pass one.

Other wishlist items, I don't know if these are really debbugs.el
issues. I'll just mention them, feel free to ignore:

i) Don't include both ###@debbugs and bug-gnu-emacs/emacs-pretest-bug in
the To:/Cc: of replies. They are basically aliases of each other, so we
just get duplicate copies if people use both. ###@debbugs is the right
address to use.

ii) In replies, replace any old emacsbugs.donarmstrong addresses with
debbugs.g.o addresses.

Re: debbugs.el revisited

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> Lars Magne Ingebrigtsen wrote:
>
>> The version number is the version number the fix has been applied to?
>> Then perhaps it could just default to sending over
>>
>> emacs-version
>> => "24.0.50.6"
>>
>> if the user doesn't override it?
>
> I think that's a bad idea. The right number to use in that case would be
> "24.1", ie the first _release_ in which something is fixed. "24.0.50.6",
> or even "24.0.50" is a meaningless version number.
> Obviously you could automatically deduce "24.1" and use that instead,
> but I think passing a version number by default is not a good idea.
> Just give the option to specify a version number when the user thinks
> it's appropriate, and otherwise don't pass one.

I've implemented it by prompting the user; she could change. The default
version number is the same as used by `report-emacs-bug', "24.0.50" this
case.

I see your point, using a _release_ number. I'll change.

Btw, <http://debbugs.gnu.org/server-control.html> documents it as

close bugnumber [ fixed-version ] (deprecated) 

What does the "deprecated" means to us?

Best regards, Michael.

Re: debbugs.el revisited

[Glenn Morris]

Michael Albinus wrote:

> close bugnumber [ fixed-version ] (deprecated) 
>
> What does the "deprecated" means to us?

To us, nothing, ignore it. :)

(Debian deprecates using "close 123" in favour of sending a message to
123-done, because the latter forces you to write an explanation, in
theory. However, debbugs.gnu.org does not deprecate close. I'll edit the
doc; as the site says somewhere, most of that stuff is generic debbugs
documentation, and not all of it is applicable to how we use it.)

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> i) Don't include both ###@debbugs and bug-gnu-emacs/emacs-pretest-bug in
> the To:/Cc: of replies. They are basically aliases of each other, so we
> just get duplicate copies if people use both. ###@debbugs is the right
> address to use.

I guess debbugs-minor-mode could set up `message-prune-recipient-rules'
to do that.  Hm...  that would be

(setq message-prune-recipient-rules
      '(("@debbugs" "bug-gnu-emacs")
        ("@debbugs" "emacs-pretest-bug")))

I think.        

> ii) In replies, replace any old emacsbugs.donarmstrong addresses with
> debbugs.g.o addresses.

And that can be done with `message-alter-recipients-function'.

I'll add this to debbugs-gnu.el.

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

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

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

>> ii) In replies, replace any old emacsbugs.donarmstrong addresses with
>> debbugs.g.o addresses.
>
> And that can be done with `message-alter-recipients-function'.
>
> I'll add this to debbugs-gnu.el.

I've now done this, but I couldn't find any donarmstrong messages to
test with, for some reason or other...

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

Re: debbugs.el revisited

[Christoph Scholtes]

On 7/2/2011 2:54 PM, Lars Magne Ingebrigtsen wrote:

> I'll add this to debbugs-gnu.el.

Is this available anywhere to try out? I didn't see it in the trunk.

Christoph

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

Christoph Scholtes <cschol2112@googlemail.com> writes:

>> I'll add this to debbugs-gnu.el.
>
> Is this available anywhere to try out? I didn't see it in the trunk.

It's in GNU ELPA, aka "the place where we put software that nobody will
ever know where to find, and will never actually use".

You can check it out from

  bzr checkout bzr+ssh://bzr.savannah.gnu.org/emacs/elpa

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

Re: debbugs.el revisited

[Lars Magne Ingebrigtsen]

I've now added a sorting command to toggle between the numerical view
and by "state" -- listing unhandled bugs first, and "done" last.

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

Re: debbugs.el revisited

[joakim]

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

> Christoph Scholtes <cschol2112@googlemail.com> writes:
>
>>> I'll add this to debbugs-gnu.el.
>>
>> Is this available anywhere to try out? I didn't see it in the trunk.
>
> It's in GNU ELPA, aka "the place where we put software that nobody will
> ever know where to find, and will never actually use".

In opensuse they had this bash hack called "zephyr". when you typed a
command that wasnt in the path it looked it up in the package database
and offered to install the corresponding package. They have the same
functionality in Fedora now but I cant find out the name of the program
that does this now.

Maybe we could have the same in Emacs? That is:

- m-x tarot

tarot isn't installed, but it is in elpa. Emacs has autoloads generated
from the elpa branch. Emacs realises tarot must be downloaded and
installed to run the command.

- prompt the user. If the user wants to:
  - download tarot from elpa
  - install
  - run tarot

Maybe it wouldnt work exactly like that, I dont know. 

>
> You can check it out from
>
>   bzr checkout bzr+ssh://bzr.savannah.gnu.org/emacs/elpa

-- 
Joakim Verona

Re: debbugs.el revisited

[Stefan Monnier]

>>>> I'll add this to debbugs-gnu.el.
>>> Is this available anywhere to try out? I didn't see it in the trunk.
>> It's in GNU ELPA, aka "the place where we put software that nobody will
>> ever know where to find, and will never actually use".
> In opensuse they had this bash hack called "zephyr". when you typed a
> command that wasnt in the path it looked it up in the package database
> and offered to install the corresponding package. They have the same
> functionality in Fedora now but I cant find out the name of the program
> that does this now.
> Maybe we could have the same in Emacs? That is:

Indeed, we could: we could process all the autoloads from GNU ELPA
packages, and "neuter" them so that instead of being really active they
just end up advertising the existence of the package.  Doing it for
arbitrary autoloads is probably impossible, but we could start by
handling a few important cases (such as command definitions and
auto-mode-alist additions).
If someone wants to take on this challenge...


        Stefan

Re: debbugs.el revisited

[Christoph Scholtes]

On 7/2/2011 3:15 PM, Lars Magne Ingebrigtsen wrote:

> It's in GNU ELPA, aka "the place where we put software that nobody will
> ever know where to find, and will never actually use".
>
> You can check it out from
>
>    bzr checkout bzr+ssh://bzr.savannah.gnu.org/emacs/elpa

Is is also available with the package.el package manager, i.e. when I 
install debbugs from it? The description in the package manager makes it 
sound like it is a generic debbugs SOAP interface.

Christoph

Re: debbugs.el revisited

[Michael Albinus]

Christoph Scholtes <cschol2112@googlemail.com> writes:

> Is is also available with the package.el package manager, i.e. when I
> install debbugs from it? The description in the package manager makes
> it sound like it is a generic debbugs SOAP interface.

Yes. But in order to be available for the archive manager, a package
must be deployed first (making a tar-ball). This is not done
automatically; for packages with very recent changes (like debbugs
today), you won't get the latest version by the package manager.

The description is not up-to-date. There is debbugs.el, which is a
generic debbugs SOAP interface, indeed. And there is debbugs-gnu.el,
which offers a UI accessing debbugs.gnu.org, for example for Emacs bugs.

> Christoph

Best regards, Michael.

Re: debbugs.el revisited

[Glenn Morris]

Lars Magne Ingebrigtsen wrote:

> I've now done this, but I couldn't find any donarmstrong messages to
> test with, for some reason or other...

Actually, recently I went back and edited all the old addresses wherever
they appeared. So that was probably a silly request, sorry. I guess any
time they still appear (which they did recently, hence me mentioning it)
is because people are replying to ~ 2 year old messages on their local
machines. Not much you can do about that...

Re: debbugs.el revisited

[Jason Rumney]

Glenn Morris <rgm@gnu.org> writes:

> Lars Magne Ingebrigtsen wrote:
>
>> The version number is the version number the fix has been applied to?
>> Then perhaps it could just default to sending over
>>
>> emacs-version
>> => "24.0.50.6"
>>
>> if the user doesn't override it?
>
> I think that's a bad idea. The right number to use in that case would be
> "24.1", ie the first _release_ in which something is fixed. "24.0.50.6",
> or even "24.0.50" is a meaningless version number.

It can be useful during pretesting to have the pretest version number in
there, so users can know whether a bug is supposed to be fixed in the
current pretest version or the next one.  But the .50 version number is
not useful, as it does not change over a long period.

Re: debbugs.el revisited

[Andreas Schwab]

Jason Rumney <jasonr@gnu.org> writes:

> But the .50 version number is not useful, as it does not change over a
> long period.

Still better than not having it at all.

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: debbugs.el revisited

[Michael Albinus]

Glenn Morris <rgm@gnu.org> writes:

> BTW, I suggest making debbugs-send-control-message prompt for and pass
> an optional version number when closing bugs. This information is very
> useful, IMO.

Done.

Best regards, Michael.