debbugs.el

debbugs.el

[Michael Albinus]

Hi,

I propose to add a small package to the trunk I have written last weeks:

;;; debbugs.el --- SOAP library to access debbugs servers

It provides some basic functions to access a debbugs SOAP server (see
<http://wiki.debian.org/DebbugsSoapInterface>). Currently, access to
debbugs.gnu.org and bugs.debian.org is offered.

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?

Best regards, Michael.

Re: debbugs.el

[Chong Yidong]

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
>
> It provides some basic functions to access a debbugs SOAP server (see
> <http://wiki.debian.org/DebbugsSoapInterface>). Currently, access to
> debbugs.gnu.org and bugs.debian.org is offered.
>
> 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.

(In which case the WSDL file would be placed in the package directory
and accessed with (file-name-directory load-file-name), as described in
the Lisp manual.)

Re: debbugs.el

[Reiner Steib]

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

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

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

[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

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

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

[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

[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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 25 Feb 2011 09:59:05 +0000
> Cc: ding@gnus.org
> 
> Or are you saying that there's no value in being able to view the status
> of the debbugs archive?

No, of course not.  Sorry I misunderstood your original message, then.

Re: debbugs.el

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
>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
>>
>> It provides some basic functions to access a debbugs SOAP server (see
>> <http://wiki.debian.org/DebbugsSoapInterface>). Currently, access to
>> debbugs.gnu.org and bugs.debian.org is offered.
>>
>> 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.
>
>(In which case the WSDL file would be placed in the package directory
>and accessed with (file-name-directory load-file-name), as described in
>the Lisp manual.)

Yidong, are you sure?  Considering that improved access to
debbugs.gnu.org helps GNU Emacs development itself, it might make sense
to have this on trunk so that maintainers always have the latest version
and don't have to do anything special to get it.

-Karl

Re: debbugs.el

[Chong Yidong]

Karl Fogel <kfogel@red-bean.com> writes:

> Considering that improved access to debbugs.gnu.org helps GNU Emacs
> development itself, it might make sense to have this on trunk so that
> maintainers always have the latest version and don't have to do
> anything special to get it.

If there is a strong concern that putting code on the package archive
makes it less accessible for Emacs developers, how about merging ELPA
into trunk builds?

That is to say, set it up (maybe optionally) so that building Emacs from
Bzr also installs the full contents of the package archive.

Re: debbugs.el

[Karl Fogel]

Chong Yidong <cyd@stupidchicken.com> writes:
>Karl Fogel <kfogel@red-bean.com> writes:
>> Considering that improved access to debbugs.gnu.org helps GNU Emacs
>> development itself, it might make sense to have this on trunk so that
>> maintainers always have the latest version and don't have to do
>> anything special to get it.
>
>If there is a strong concern that putting code on the package archive
>makes it less accessible for Emacs developers, how about merging ELPA
>into trunk builds?
>
>That is to say, set it up (maybe optionally) so that building Emacs from
>Bzr also installs the full contents of the package archive.

I think that's an interesting idea, and wish I could help.

It's not a major blocker either way, since certainly maintainers can use
the package archive, with a little more effort.  I personally would be
somewhat more likely to use debbugs.el if it were in trunk, but maybe
this will just spur me to learn to use ELPA as a matter of course too.

I guess I don't have a strong argument to make, just a mild preference
for having it in trunk.  Your call.

Re: debbugs.el

[Stephen J. Turnbull]

Chong Yidong writes:
 > Karl Fogel <kfogel@red-bean.com> writes:
 > 
 > > Considering that improved access to debbugs.gnu.org helps GNU Emacs
 > > development itself, it might make sense to have this on trunk so that
 > > maintainers always have the latest version and don't have to do
 > > anything special to get it.
 > 
 > If there is a strong concern that putting code on the package archive
 > makes it less accessible for Emacs developers, how about merging ELPA
 > into trunk builds?

This doesn't help at the other end.  If it's in trunk, Emacs
developers will hack on it.  If not, it's Somebody Else's
Business[tm], and they are far less likely to do so.

Thus-spake-the-voice-of-ten-years'-experiencely y'rs,

Re: debbugs.el

[Ted Zlatanov]

On Fri, 25 Feb 2011 09:42:43 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

SJT> Chong Yidong writes:
>> Karl Fogel <kfogel@red-bean.com> writes:
>> 
>> > Considering that improved access to debbugs.gnu.org helps GNU Emacs
>> > development itself, it might make sense to have this on trunk so that
>> > maintainers always have the latest version and don't have to do
>> > anything special to get it.
>> 
>> If there is a strong concern that putting code on the package archive
>> makes it less accessible for Emacs developers, how about merging ELPA
>> into trunk builds?

SJT> This doesn't help at the other end.  If it's in trunk, Emacs
SJT> developers will hack on it.  If not, it's Somebody Else's
SJT> Business[tm], and they are far less likely to do so.

This is why I suggested the elpa.gnu.org files should simply be in a
subdirectory of the Emacs trunk but the maintainers preferred they be
separate.  Maybe now, after a few months of offering elpa.gnu.org, it
can be reevaluated.

Ted

Re: debbugs.el

[Stefan Monnier]

> This is why I suggested the elpa.gnu.org files should simply be in a
> subdirectory of the Emacs trunk but the maintainers preferred they be
> separate.  Maybe now, after a few months of offering elpa.gnu.org, it
> can be reevaluated.

There is no question that the ELPA archive should be in a different Bzr
branch than Emacs.  But we should encourage (e.g. by making it very
easy) having both checkouts.


        Stefan

elpa.gnu.org packages in an Emacs checkout (was: debbugs.el)

[Ted Zlatanov]

On Fri, 25 Feb 2011 10:47:39 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> This is why I suggested the elpa.gnu.org files should simply be in a
>> subdirectory of the Emacs trunk but the maintainers preferred they be
>> separate.  Maybe now, after a few months of offering elpa.gnu.org, it
>> can be reevaluated.

SM> There is no question that the ELPA archive should be in a different Bzr
SM> branch than Emacs.  But we should encourage (e.g. by making it very
SM> easy) having both checkouts.

Is there a way to set it up so a) checking out Emacs from Bazaar gives
the elpa.gnu.org (GNU ELPA) code branch as well, and b) changes made in
such a checkout propagate back to the GNU ELPA branch?  That seems like
a lot of magic but Bazaar seems to excel in magic :)

If so, the difference is server-side and won't matter to the
developers.  But otherwise we should revise the instructions for
checking out Emacs to make it clear the GNU ELPA code is part of Emacs
and should be checked out alongside.

Ted

Re: elpa.gnu.org packages in an Emacs checkout

[Glenn Morris]

Ted Zlatanov wrote:

> Is there a way to set it up so a) checking out Emacs from Bazaar gives
> the elpa.gnu.org (GNU ELPA) code branch as well, and b) changes made in
> such a checkout propagate back to the GNU ELPA branch?

IMO, that's unnecessary and defeats part of the purpose of branches.
I had no problems checking out the elpa branch.

> But otherwise we should revise the instructions for
> checking out Emacs to make it clear the GNU ELPA code is part of Emacs
> and should be checked out alongside.

Definite yes to documenting it, though.

Re: elpa.gnu.org packages in an Emacs checkout

[Ted Zlatanov]

On Fri, 25 Feb 2011 12:49:46 -0500 Glenn Morris <rgm@gnu.org> wrote: 

GM> Ted Zlatanov wrote:
>> Is there a way to set it up so a) checking out Emacs from Bazaar gives
>> the elpa.gnu.org (GNU ELPA) code branch as well, and b) changes made in
>> such a checkout propagate back to the GNU ELPA branch?

GM> IMO, that's unnecessary and defeats part of the purpose of branches.
GM> I had no problems checking out the elpa branch.

I was thinking out loud.  Disregard.

>> But otherwise we should revise the instructions for
>> checking out Emacs to make it clear the GNU ELPA code is part of Emacs
>> and should be checked out alongside.

GM> Definite yes to documenting it, though.

OK.  Which ones of:

nt/INSTALL
doc/emacs/maintaining.texi
doc/emacs/anti.texi
doc/misc/faq.texi
admin/notes/bzr
admin/notes/bugtracker
admin/bzrmerge.el
INSTALL
INSTALL.BZR
etc/THE-GNU-PROJECT
etc/CONTRIBUTE

should I do (trying to avoid unnecessary modifications)?

I can also modify the Emacs Wiki pages accordingly.

Ted

Re: elpa.gnu.org packages in an Emacs checkout

[Michael Albinus]

Ted Zlatanov <tzz@lifelogs.com> writes:

>>> But otherwise we should revise the instructions for
>>> checking out Emacs to make it clear the GNU ELPA code is part of Emacs
>>> and should be checked out alongside.
>
> GM> Definite yes to documenting it, though.
>
> OK.  Which ones of:
>
> nt/INSTALL
> doc/emacs/maintaining.texi
> doc/emacs/anti.texi
> doc/misc/faq.texi
> admin/notes/bzr
> admin/notes/bugtracker
> admin/bzrmerge.el
> INSTALL
> INSTALL.BZR
> etc/THE-GNU-PROJECT
> etc/CONTRIBUTE
>
> should I do (trying to avoid unnecessary modifications)?

admin/notes/elpa seems also being outdated[1]. I failed to apply the
instructions.

[1]: Or I am too stupid.

> I can also modify the Emacs Wiki pages accordingly.
>
> Ted

Best regards, Michael.

Re: elpa.gnu.org packages in an Emacs checkout

[Glenn Morris]

Ted Zlatanov wrote:

> OK.  Which ones of:
>
> nt/INSTALL
> doc/emacs/maintaining.texi
> doc/emacs/anti.texi
> doc/misc/faq.texi
> admin/notes/bzr
> admin/notes/bugtracker
> admin/bzrmerge.el
> INSTALL
> INSTALL.BZR
> etc/THE-GNU-PROJECT
> etc/CONTRIBUTE
>
> should I do (trying to avoid unnecessary modifications)?

Several of those suggestions make no sense (perhaps I missed the sarcasm).

I would say for sure mention elpa.gnu.org in:

doc/misc/faq.texi
etc/MORE.STUFF
etc/NEWS (already a brief mention I see)

and at some point closer to the release in the Emacs manual.

I wouldn't mention the bzr branch in any of those places, because that
detail is not relevant to users. They should just go through
elpa.gnu.org. Is there any reason users need to know about the bzr
branch at all? It could be mentioned in a note on http://elpa.gnu.org.

As to documenting the existence of the elpa branch for developers, I
don't know what there is to say, but I think admin/notes/elpa is the
right place.

But see what others think since I haven't thought about this much.