Re: debbugs.el

Re: debbugs.el

[Michael Albinus]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

[Cc to ding@gnus.org]

> On Wed, Feb 23 2011, Chong Yidong wrote:
>
>> Michael Albinus <michael.albinus@gmx.de> writes:
>>
>>> I propose to add a small package to the trunk I have written last weeks:
>>>
>>> ;;; debbugs.el --- SOAP library to access debbugs servers
> [...]
>>> Those functions could be used to implement a UI towards debbugs,
>>> widget-based or via gnus/nnir.
>>>
>>> For installation, the package needs also a WSDL file (Debbugs.wsdl). I
>>> have no idea where to install this file, maybe at etc/ ?
>>>
>>> Comments?
>>
>> This sounds more suitable for elpa.gnu.org than the trunk.
>
> I think we need a better interface to our bug tracker[1].  It would be
> better to have it in Emacs so that Gnus (nnir, message mode, ...) can
> build upon it.
>
> [1] handling bugs as described in admin/notes/bugtracker: closing,
>     merging, tagging, setting severity, ...

That was my motivation writing debbugs.el. I've also started an nnir
integration, but I failed badly due to missing gnus knowledge.

OTOH, the debbugs SOAP interface is poor, there are only very basic
information one could retrieve, and there is no "activiation" function
(changing whatever for a bug). So it might be better, we first make a
prototype implementation integrating it with nnir etc, before adding it
to Emacs core. For this purpose, it might be sufficient to bring it to
elpa (or gnus) for a while.

I would volunteer to participate in this integration work. I have
learned, I'm not able to do it alone.

> Bye, Reiner.

Best regards, Michael.

Re: debbugs.el

[Evgeny M. Zubok]

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

> That was my motivation writing debbugs.el. I've also started an nnir
> integration, but I failed badly due to missing gnus knowledge.

There is debian-el package in Debian repository. It is also the suitable
place to push debbugs.el into. debian-el has a number of useful
features: you can file a bug with (debian-bug), fill the tags in the
mail body, compose control messages for control@bugs.debian.org
(debian-bts-control), download mbox with log of selected bug number,
view this mbox in Gnus as a tree (debian-bug-get-bug-as-email), reply to
someone.

> OTOH, the debbugs SOAP interface is poor, there are only very basic
> information one could retrieve, and there is no "activiation" function
> (changing whatever for a bug). So it might be better, we first make a
> prototype implementation integrating it with nnir etc, before adding it
> to Emacs core. For this purpose, it might be sufficient to bring it to
> elpa (or gnus) for a while.

I made an attempt to create Emacs interface to Debbugs/SOAP year
ago. I've wrote a simple SOAP client library in Emacs Lisp. By using
this library my debbugs-mode requested for a bug list (filtered by
different parameters: package, severity, tags, etc.) along with the
status information for every bug. Bug reports are grouped by severity,
sorted by bug number and displayed in outline-mode (folding/unfolding
out of a box).

One year old screenshot:

http://s006.radikal.ru/i214/1001/d1/08ef5f85246e.png

I didn't use the SOAP to request the bug logs because Debbugs/SOAP won't
send the attachments. When I hit RET against the bug entry, the
maintainer's mbox for selected bug is downloaded. mbox can be opened
either in Gnus or in RMAIL. I used the latter to be neutral to the users
of different mail programs: Gnus, Wunderlust, etc. Any message from the
log can be replied with your favourite mail program (Gnus in my case).

My work can be viewed as early technical preview; it has many dirty
hacks (hardcoded XML namespaces in SOAP client library is the most
simple example), bugs. The code is ugly, I was in hurry to make the mode
work. That's because it's not published yet. :)

I want to start hacking again and hope to finish it some day. :)

Re: debbugs.el

[Lars Ingebrigtsen]

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

> OTOH, the debbugs SOAP interface is poor, there are only very basic
> information one could retrieve, and there is no "activiation" function
> (changing whatever for a bug). So it might be better, we first make a
> prototype implementation integrating it with nnir etc, before adding it
> to Emacs core. For this purpose, it might be sufficient to bring it to
> elpa (or gnus) for a while.

I'd love to have a real Emacs-based interface to the Emacs bug archive.
I'd be checking it a lot more often.  These days I need to remember to
point a web browser at it, see if there's anything interesting, and then
type `M-x gnus-read-ephemeral-emacs-bug-group RET <that bug number>
RET', and that's just boring.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: debbugs.el

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 24 Feb 2011 19:37:36 -0800
> Cc: ding@gnus.org, emacs-devel@gnu.org
> 
> I'd love to have a real Emacs-based interface to the Emacs bug archive.
> I'd be checking it a lot more often.  These days I need to remember to
> point a web browser at it, see if there's anything interesting, and then
> type `M-x gnus-read-ephemeral-emacs-bug-group RET <that bug number>
> RET', and that's just boring.

Or make the bugs come to you: subscribe to the bug-gnu-emacs@gnu.org
mailing list, and that's it.

Re: debbugs.el

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Date: Thu, 24 Feb 2011 19:37:36 -0800
>> Cc: ding@gnus.org, emacs-devel@gnu.org
>> 
>> I'd love to have a real Emacs-based interface to the Emacs bug archive.
>> I'd be checking it a lot more often.  These days I need to remember to
>> point a web browser at it, see if there's anything interesting, and then
>> type `M-x gnus-read-ephemeral-emacs-bug-group RET <that bug number>
>> RET', and that's just boring.
>
> Or make the bugs come to you: subscribe to the bug-gnu-emacs@gnu.org
> mailing list, and that's it.

The idea of the debbugs SOAP interface is to send queries. Of yourse you
could do it in your local email archive (or via the corresponding
gmane.org group), but this is questionable when you have 615045 tickets
like at bugs.debian.org this morning.

Best regards, Michael.

Re: debbugs.el

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  ding@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Feb 2011 09:33:22 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Lars Ingebrigtsen <larsi@gnus.org>
> >> Date: Thu, 24 Feb 2011 19:37:36 -0800
> >> Cc: ding@gnus.org, emacs-devel@gnu.org
> >> 
> >> I'd love to have a real Emacs-based interface to the Emacs bug archive.
> >> I'd be checking it a lot more often.  These days I need to remember to
> >> point a web browser at it, see if there's anything interesting, and then
> >> type `M-x gnus-read-ephemeral-emacs-bug-group RET <that bug number>
> >> RET', and that's just boring.
> >
> > Or make the bugs come to you: subscribe to the bug-gnu-emacs@gnu.org
> > mailing list, and that's it.
> 
> The idea of the debbugs SOAP interface is to send queries.

I'm all for it, mind you.  I just think that the reasons stated by
Lars are not a valid justification for having such an interface in
Emacs.

Re: debbugs.el

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> >> I'd love to have a real Emacs-based interface to the Emacs bug archive.
>> >> I'd be checking it a lot more often.  These days I need to remember to
>> >> point a web browser at it, see if there's anything interesting, and then
>> >> type `M-x gnus-read-ephemeral-emacs-bug-group RET <that bug number>
>> >> RET', and that's just boring.
>> >
>> > Or make the bugs come to you: subscribe to the bug-gnu-emacs@gnu.org
>> > mailing list, and that's it.
>> 
>> The idea of the debbugs SOAP interface is to send queries.
>
> I'm all for it, mind you.  I just think that the reasons stated by
> Lars are not a valid justification for having such an interface in
> Emacs.

"I'd be checking it a lot more often" seems like pretty good
justification to me...

The mailing list is useful too, but it isn't a good replacement for a
query-based interface (I suspect that very active maintainers would use
both, but that many occasional participants would general prefer a
query-based interface).

-Miles

-- 
Religion, n. A daughter of Hope and Fear, explaining to Ignorance the nature
of the Unknowable.

Re: debbugs.el

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Michael Albinus <michael.albinus@gmx.de>, larsi@gnus.org, ding@gnus.org,
>  emacs-devel@gnu.org
> Date: Fri, 25 Feb 2011 18:29:25 +0900
> 
> > I'm all for it, mind you.  I just think that the reasons stated by
> > Lars are not a valid justification for having such an interface in
> > Emacs.
> 
> "I'd be checking it a lot more often" seems like pretty good
> justification to me...

?? If you are subscribed to the mailing list, the bugs are already in
your mailbox.  So why would you need to "check" debbugs, just to know
about their existence?

Querying the database when actually _working_ on bugs is another
matter, and that is IMO the real reason for having this interface.
But just to know that a bug related to one's work or interests exist,
you can easily do with the mailing list.

Re: debbugs.el

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Or make the bugs come to you: subscribe to the bug-gnu-emacs@gnu.org
> mailing list, and that's it.

I do read that list.  The purpose of a debbugs interface is to read (and
check) the status of older bugs.

Or are you saying that there's no value in being able to view the status
of the debbugs archive?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: debbugs.el

[Michael Albinus]

"Evgeny M. Zubok" <evgeny.zubok@tochka.ru> writes:

Hi Evgeny,

>> That was my motivation writing debbugs.el. I've also started an nnir
>> integration, but I failed badly due to missing gnus knowledge.
>
> There is debian-el package in Debian repository. It is also the suitable
> place to push debbugs.el into. debian-el has a number of useful
> features: you can file a bug with (debian-bug), fill the tags in the
> mail body, compose control messages for control@bugs.debian.org
> (debian-bts-control), download mbox with log of selected bug number,
> view this mbox in Gnus as a tree (debian-bug-get-bug-as-email), reply to
> someone.

debian-el is intended for Debian GNU/Linux based distributions. Only a
minority(?) of Emacs users use it.

>> OTOH, the debbugs SOAP interface is poor, there are only very basic
>> information one could retrieve, and there is no "activiation" function
>> (changing whatever for a bug). So it might be better, we first make a
>> prototype implementation integrating it with nnir etc, before adding it
>> to Emacs core. For this purpose, it might be sufficient to bring it to
>> elpa (or gnus) for a while.
>
> I made an attempt to create Emacs interface to Debbugs/SOAP year
> ago. I've wrote a simple SOAP client library in Emacs Lisp. By using
> this library my debbugs-mode requested for a bug list (filtered by
> different parameters: package, severity, tags, etc.) along with the
> status information for every bug. Bug reports are grouped by severity,
> sorted by bug number and displayed in outline-mode (folding/unfolding
> out of a box).
>
> One year old screenshot:
>
> http://s006.radikal.ru/i214/1001/d1/08ef5f85246e.png

That includes both frontend and backend. For better exploitation,
debbugs.el is intended to offer backend functionality only, it does not
care about any UI.

> I didn't use the SOAP to request the bug logs because Debbugs/SOAP won't
> send the attachments.

Indeed. However, an empty "attachment" attribute is returned; it might
be just a question of implementing it server side.

> When I hit RET against the bug entry, the maintainer's mbox for
> selected bug is downloaded. mbox can be opened either in Gnus or in
> RMAIL. I used the latter to be neutral to the users of different mail
> programs: Gnus, Wunderlust, etc. Any message from the log can be
> replied with your favourite mail program (Gnus in my case).

This is useful when the frontend is something related to email
display/reply. It might also have a better performance than the SOAP
based retrieval (I haven't checked). Maybe both alternatives for message
retrieval shall be offered by the backend.

> My work can be viewed as early technical preview; it has many dirty
> hacks (hardcoded XML namespaces in SOAP client library is the most
> simple example), bugs. The code is ugly, I was in hurry to make the mode
> work. That's because it's not published yet. :)

That's how I also started mid of 2009. Last year, I switched to
soap-client.el (recently added to Emacs' trunk). My code is much less
ugly now.

I've also written a frontend similar to what you have done, but it is
based on widgets instead of outline mode. Like yours, it is unfinished.

> I want to start hacking again and hope to finish it some day. :)

Let's do it together. We could merge the backend functionality into
debbugs.el, and continue to work on the different frontends. As I have
said already, I would also be interested in an nnir integration.

And I believe also, that the debbugs SOAP interface should be
improved. From my todo list:

;; * SOAP interface extensions (wishlist).
;;   - Server-side sorting.
;;   - Regexp and/or wildcards search.
;;   - Fulltext search.

Best regards, Michael.

Re: debbugs.el

[Stefan Monnier]

> ?? If you are subscribed to the mailing list, the bugs are already in
> your mailbox.  So why would you need to "check" debbugs, just to know
> about their existence?

For Emacs maintainers, that's mostly true, but for maintainers of some
particular (set of) packages, it's not so easy: reports that interest
them can get drowned in the rest.


        Stefan

Re: debbugs.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Miles Bader <miles@gnu.org>,  larsi@gnus.org,  michael.albinus@gmx.de,  ding@gnus.org,  emacs-devel@gnu.org
> Date: Fri, 25 Feb 2011 10:43:06 -0500
> 
> > ?? If you are subscribed to the mailing list, the bugs are already in
> > your mailbox.  So why would you need to "check" debbugs, just to know
> > about their existence?
> 
> For Emacs maintainers, that's mostly true, but for maintainers of some
> particular (set of) packages, it's not so easy: reports that interest
> them can get drowned in the rest.

I think we all can read mail efficiently enough to avoid that.

Re: debbugs.el

[Evgeny M. Zubok]

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

>> One year old screenshot:
>>
>> http://s006.radikal.ru/i214/1001/d1/08ef5f85246e.png
>
> That includes both frontend and backend. For better exploitation,
> debbugs.el is intended to offer backend functionality only, it does
> not care about any UI.

> I've also written a frontend similar to what you have done, but it is
> based on widgets instead of outline mode. Like yours, it is
> unfinished.

My solution is also have a layered architecture: (i) a separate package
with generic SOAP client library; (ii) a separate package with
debbugs-soap.el as backend; (iii) debian-bts mode as a frontend. One of
my initial design consideration was to allow custom
frontends. debbugs-soap.el backend is very small library. It only
performs the requests to Debbugs server such as: get_bugs, get_status,
get_versions, get_bug_log, etc. All mbox functionality currently
implemented in frontend. I think it's a good idea to move it into
backend as alternative (to SOAP) method of receiving logs from server.

> That's how I also started mid of 2009. Last year, I switched to
> soap-client.el (recently added to Emacs' trunk). My code is much less
> ugly now.

This library appeared at the same time with my library. I was going to
prepare my soap-client.el for Emacs but someone is way faster than
me. :) Well, I will help soap-client.el from 'trunk' with patches. :)

>> I want to start hacking again and hope to finish it some day. :)
>
> Let's do  it together. We  could merge the backend  functionality into
> debbugs.el, and continue to work on the different frontends. As I have
> said already, I would also be interested in an nnir integration.

Is your project published somewhere?

Re: debbugs.el

[Michael Albinus]

"Evgeny M. Zubok" <evgeny.zubok@tochka.ru> writes:

Hi Evgeny,

> My solution is also have a layered architecture: (i) a separate package
> with generic SOAP client library; (ii) a separate package with
> debbugs-soap.el as backend; (iii) debian-bts mode as a frontend. One of
> my initial design consideration was to allow custom
> frontends. debbugs-soap.el backend is very small library. It only
> performs the requests to Debbugs server such as: get_bugs, get_status,
> get_versions, get_bug_log, etc. All mbox functionality currently
> implemented in frontend. I think it's a good idea to move it into
> backend as alternative (to SOAP) method of receiving logs from server.

Yes.

>> That's how I also started mid of 2009. Last year, I switched to
>> soap-client.el (recently added to Emacs' trunk). My code is much less
>> ugly now.
>
> This library appeared at the same time with my library. I was going to
> prepare my soap-client.el for Emacs but someone is way faster than
> me. :) Well, I will help soap-client.el from 'trunk' with patches. :)

Thanks. In fact, the author of soap-client.el is Alex Harsanyi, who
maintains it uptstream.

Btw, if you intend to contribute for Emacs, you shall sign the FSF legal
papers. Have you started this procedure already?

>> Let's do  it together. We  could merge the backend  functionality into
>> debbugs.el, and continue to work on the different frontends. As I have
>> said already, I would also be interested in an nnir integration.
>
> Is your project published somewhere?

Not (yet). I'm just rying to bring it to elpa, as proposed by Chong, but
I have problems with this. If you want, I could send you my debbugs.el
via email.

Best regards, Michael.

Re: debbugs.el

[Evgeny M. Zubok]

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

> Thanks. In fact, the author of soap-client.el is Alex Harsanyi, who
> maintains it uptstream.
>
> Btw, if you intend to contribute for Emacs, you shall sign the FSF
> legal papers. Have you started this procedure already?

I'm going to sing FSF papers soon, otherwise, I will not be able to
contribute.

>> Is your project published somewhere?
>
> Not (yet). I'm just rying to bring it to elpa, as proposed by Chong,
> but I have problems with this. If you want, I could send you my
> debbugs.el via email.

That's ok. My e-mail is in headers. I will need some time to learn the
source and make it work on my Emacs. I'm still using the old Emacs 22.2
from Debian Lenny. The soap-client.el has been included to trunk
later. I've found its source but didn't try it yet.