bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Stefan Kangas]

One user reports:

    That change fixes the issue! Great! Let’s file a bug and then submit the
    fix for it… except… the project.el file contains absolutely no
    information about how to submit bugs or patches. There’s nothing on the
    project.el web page. No websites, no bug tracker, no email addresses.

    Folks, if you maintain Open Source software and you ever wonder why
    you’re not getting contributions… this is why you’re not getting
    contributions: because you don’t spend any time thinking about making it
    easy (or in this case, even possible) for folks to contribute back to
    your project.

    So, instead of supplying a bug report and a patch, so that other folks
    might avoid this problem when they upgrade their Emacs packages (and
    instead of working on PROJECT APOLLO, like I planned to do today), I’m
    writing this blog post. Hopefully, after I post this online in a few
    places, Cunningham’s Law will kick in and somebody will show up and tell
    me where I can send this patch after all…

    https://genehack.blog/2020/05/open-source-annoyances-and-affordances/

I think this is situation could be alleviated by including a static
section on the pages for individual packages which explains how to
report bugs.

Best regards,
Stefan Kangas

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Glenn Morris]

Stefan Kangas wrote:

> I think this is situation could be alleviated by including a static
> section on the pages for individual packages which explains how to
> report bugs.

This will vary from package to package. I doubt "M-x report-emacs-bug"
is right in anything more than a small minority of cases (because it
would require the package developer to subscribe to bug-gnu-emacs).
I would think that the package itself needs to contain its bug reporting
information, independent of elpa.gnu.org.

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 17 May 2020 19:14:57 -0700
> 
> One user reports:
> 
>     That change fixes the issue! Great! Let’s file a bug and then submit the
>     fix for it… except… the project.el file contains absolutely no
>     information about how to submit bugs or patches. There’s nothing on the
>     project.el web page. No websites, no bug tracker, no email addresses.
> 
>     Folks, if you maintain Open Source software and you ever wonder why
>     you’re not getting contributions… this is why you’re not getting
>     contributions: because you don’t spend any time thinking about making it
>     easy (or in this case, even possible) for folks to contribute back to
>     your project.
> 
>     So, instead of supplying a bug report and a patch, so that other folks
>     might avoid this problem when they upgrade their Emacs packages (and
>     instead of working on PROJECT APOLLO, like I planned to do today), I’m
>     writing this blog post. Hopefully, after I post this online in a few
>     places, Cunningham’s Law will kick in and somebody will show up and tell
>     me where I can send this patch after all…
> 
>     https://genehack.blog/2020/05/open-source-annoyances-and-affordances/
> 
> I think this is situation could be alleviated by including a static
> section on the pages for individual packages which explains how to
> report bugs.

Is this about project.el that's in Emacs?  That one says it is part of
GNU Emacs, like any other bundled package, and thus bugs should be
reported to the Emacs bug tracker, see "emacs --help".  Not sure what
you mean by "pages for individual packages".

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Dmitry Gutov]

On 18.05.2020 05:14, Stefan Kangas wrote:
> I think this is situation could be alleviated by including a static
> section on the pages for individual packages which explains how to
> report bugs.

Since the example was about project.el, we could limit our response to 
adding an explanatory section to :core packages.

I have a rough patch ready, but having trouble building the HTML pages 
of GNU ELPA locally thus far.

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 18.05.2020 05:14, Stefan Kangas wrote:
>> I think this is situation could be alleviated by including a static
>> section on the pages for individual packages which explains how to
>> report bugs.
>
> Since the example was about project.el, we could limit our response to
> adding an explanatory section to :core packages.
>
> I have a rough patch ready, but having trouble building the HTML pages
> of GNU ELPA locally thus far.

Indeed, that probably makes more sense.  Thanks.

Best regards,
Stefan Kangas

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Not sure what you mean by "pages for individual packages".

For example: https://elpa.gnu.org/packages/project.html

Best regards,
Stefan Kangas

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

We could have report-emacs-bug ask for which package the bug is in.
The Bug Subject argument could be one of the acceptable package names,
including 'emacs' and whichever ELPA packages have been loaded.  The
user could specify one of those.

If the definition of a package says where to send bug reports for it,
report-emacs-bug could send each bug to the right place.

If Bug Subject argument isn't on that list, report-emacs-bug could ask,
"Would you like to specify one of the ELPA packages that have been
loaded?"  But you would not have to do that.  If Bug Subject is unknown,
the message would go to bug-gnu-emacs, as now.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

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

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> We could have report-emacs-bug ask for which package the bug is in.
> The Bug Subject argument could be one of the acceptable package names,
> including 'emacs' and whichever ELPA packages have been loaded.  The
> user could specify one of those.
>
> If the definition of a package says where to send bug reports for it,
> report-emacs-bug could send each bug to the right place.
>
> If Bug Subject argument isn't on that list, report-emacs-bug could ask,
> "Would you like to specify one of the ELPA packages that have been
> loaded?"  But you would not have to do that.  If Bug Subject is unknown,
> the message would go to bug-gnu-emacs, as now.

Several years ago I cooked up something basic like that. I've attached
the patch from that thread, which might serve as the basis for something
usable.

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Cc-package-maintainers-when-reporting-emacs-bugs.patch --]
[-- Type: text/x-patch, Size: 2480 bytes --]

From 542d7b342d0ce86933d8c6998ca7a817952b0b3f Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Thu, 21 Jul 2016 15:58:47 -0400
Subject: [PATCH] Cc package maintainers when reporting emacs bugs

* lisp/mail/emacsbug.el (report-emacs-bug): Prompt for a package to
  report a bug against, and cc the package maintainer, if any, on the
  bug report.
---
 lisp/mail/emacsbug.el | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index 18eaa22..87ac234 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -144,11 +144,17 @@ message-send-mail-function
 (defvar message-sendmail-envelope-from)

 ;;;###autoload
-(defun report-emacs-bug (topic &optional unused)
+(defun report-emacs-bug (topic package &optional unused)
   "Report a bug in GNU Emacs.
 Prompts for bug subject.  Leaves you in a mail buffer."
   (declare (advertised-calling-convention (topic) "24.5"))
-  (interactive "sBug Subject: ")
+  (interactive (list
+                (read-string "Bug Subject: ")
+                (completing-read
+                 "Package: "
+                 (progn
+                   (package-initialize)
+                   package-alist))))
   ;; The syntax `version;' is preferred to `[version]' because the
   ;; latter could be mistakenly stripped by mailing software.
   (if (eq system-type 'ms-dos)
@@ -158,6 +164,9 @@ report-emacs-bug
   (let ((from-buffer (current-buffer))
 	(can-insert-mail (or (report-emacs-bug-can-use-xdg-email)
 			     (report-emacs-bug-can-use-osx-open)))
+        (cc (unless (or (string-empty-p package) (string= package "emacs"))
+              (require 'finder)
+              (lm-maintainer (find-library-name package))))
         user-point message-end-point)
     (setq message-end-point
 	  (with-current-buffer (messages-buffer)
@@ -184,6 +193,13 @@ report-emacs-bug
       (when (and (not message-sendmail-envelope-from)
 		 (message-bogus-recipient-p (message-make-address)))
 	(set (make-local-variable 'message-sendmail-envelope-from) 'header)))
+    (when (cdr cc) ;; The cdr is the email address.
+      (if (derived-mode-p 'message-mode)
+          (message-goto-cc)
+        (mail-cc))
+      (if (car cc)
+          (insert (format "%s <%s>" (car cc) (cdr cc)))
+        (insert (format "%s" (cdr cc)))))
     (rfc822-goto-eoh)
     (forward-line 1)
     ;; Move the mail signature to the proper place.
--
2.9.0

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Bastien]

Hi Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>> We could have report-emacs-bug ask for which package the bug is in.
>> The Bug Subject argument could be one of the acceptable package names,
>> including 'emacs' and whichever ELPA packages have been loaded.  The
>> user could specify one of those.
>>
>> If the definition of a package says where to send bug reports for it,
>> report-emacs-bug could send each bug to the right place.
>>
>> If Bug Subject argument isn't on that list, report-emacs-bug could ask,
>> "Would you like to specify one of the ELPA packages that have been
>> loaded?"  But you would not have to do that.  If Bug Subject is unknown,
>> the message would go to bug-gnu-emacs, as now.
>
> Several years ago I cooked up something basic like that. I've attached
> the patch from that thread, which might serve as the basis for something
> usable.

I tested your patch and it looks really useful to me.

Two things that come to my mind:

- Package completion could not find "org" as a package: still, a bare
  emacs -q list Org as a built-in package.  Maybe we can add those to
  the completion list?

- If completion fails, then the bug reporting process is stopped,
  which may be confusing for users -- when there is no completion,
  I suggest to fall back on the current report-emacs-bug behavior.

- I wonder what happens if the "maintainer" email is a mailing list
  address: this might lead to confusion, with people cross-posting to
  both bug-gnu-emacs@gnu.org and emacs-orgmode@gnu.org for example,
  which would perhaps lead to some more confusion because bugs on
  bug-gnu-emacs@gnu.org are posted to emacs-orgmode@gnu.org when they
  are tagged "org-mode" (if I understand correctly).

A simple solution for the last issue would be to forbid mailing list
addresses in the "maintainer" email field.  In the case of org-mode,
for example, the address could be that of someone in charge of doing
bug triage, assigning tags to bug-gnu-emacs@gnu.org when needed.

In any case, thanks for spending time on this!

-- 
 Bastien

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Dmitry Gutov]

On 20.05.2020 06:54, Richard Stallman wrote:
> We could have report-emacs-bug ask for which package the bug is in.
> The Bug Subject argument could be one of the acceptable package names,
> including 'emacs' and whichever ELPA packages have been loaded.  The
> user could specify one of those.

I hope people understand that this won't solve the problem reported by 
the user: they didn't know that 'M-x report-emacs-bug' should be used in 
this case at all.

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

Bastien <bzg@gnu.org> writes:

> Hi Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>> We could have report-emacs-bug ask for which package the bug is in.
>>> The Bug Subject argument could be one of the acceptable package names,
>>> including 'emacs' and whichever ELPA packages have been loaded.  The
>>> user could specify one of those.
>>>
>>> If the definition of a package says where to send bug reports for it,
>>> report-emacs-bug could send each bug to the right place.
>>>
>>> If Bug Subject argument isn't on that list, report-emacs-bug could ask,
>>> "Would you like to specify one of the ELPA packages that have been
>>> loaded?"  But you would not have to do that.  If Bug Subject is unknown,
>>> the message would go to bug-gnu-emacs, as now.
>>
>> Several years ago I cooked up something basic like that. I've attached
>> the patch from that thread, which might serve as the basis for something
>> usable.
>
> I tested your patch and it looks really useful to me.
>
> Two things that come to my mind:
>
> - Package completion could not find "org" as a package: still, a bare
>   emacs -q list Org as a built-in package.  Maybe we can add those to
>   the completion list?

I think in the original discussion the patch went back and forth between
completing on `package-alist' and completing on `features'. The former
didn't offer enough, the latter offered too much.

> - If completion fails, then the bug reporting process is stopped,
>   which may be confusing for users -- when there is no completion,
>   I suggest to fall back on the current report-emacs-bug behavior.

Yes, that's a bug! It shouldn't require a package.

> - I wonder what happens if the "maintainer" email is a mailing list
>   address: this might lead to confusion, with people cross-posting to
>   both bug-gnu-emacs@gnu.org and emacs-orgmode@gnu.org for example,
>   which would perhaps lead to some more confusion because bugs on
>   bug-gnu-emacs@gnu.org are posted to emacs-orgmode@gnu.org when they
>   are tagged "org-mode" (if I understand correctly).

If we complete on `features', that's definitely an issue. I think my
solution in that version of the patch simply dropped the issue if the
Maintainer header was emacs-devel, or there was no Maintainer.

> A simple solution for the last issue would be to forbid mailing list
> addresses in the "maintainer" email field.  In the case of org-mode,
> for example, the address could be that of someone in charge of doing
> bug triage, assigning tags to bug-gnu-emacs@gnu.org when needed.
>
> In any case, thanks for spending time on this!

My pleasure -- as Dmitry notes, this might not solve the problem that
this thread is about, but I think it's definitely worthwhile on its own.

Eric

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Glenn Morris]

This should use "X-Debbugs-CC" rather than "Cc".
Experience with c-submit-bug-report is that some mail clients don't
support X- headers, so it should also add a pseudo-header to the start
of the message body.

Maintainers of some packages may have no interest in interacting with
debbugs.gnu.org, so Someone will need to tidy up those reports.

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

Glenn Morris <rgm@gnu.org> writes:

> This should use "X-Debbugs-CC" rather than "Cc".
> Experience with c-submit-bug-report is that some mail clients don't
> support X- headers, so it should also add a pseudo-header to the start
> of the message body.

Thanks for these notes! I'll make this change.

> Maintainers of some packages may have no interest in interacting with
> debbugs.gnu.org, so Someone will need to tidy up those reports.

By "tidy up" do you mean close the reports and let them get resolved
elsewhere? Interacting with debbugs seems fairly low-overhead when it's
just a matter of keeping it in the cc.

Thanks again,
Eric

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Bastien]

Hi Eric,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I think in the original discussion the patch went back and forth between
> completing on `package-alist' and completing on `features'. The former
> didn't offer enough, the latter offered too much.

While not offering "enough", the former is already an improvement, I'd
be in favor of implementing it.  The latter really offers too much IMO.

> If we complete on `features', that's definitely an issue. I think my
> solution in that version of the patch simply dropped the issue if the
> Maintainer header was emacs-devel, or there was no Maintainer.

Yes, it looks fine to me like this.

> My pleasure -- as Dmitry notes, this might not solve the problem that
> this thread is about, but I think it's definitely worthwhile on its own.

Definitely.  What is still needed here so that you can make this change?

-- 
 Bastien

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

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


On 06/01/20 08:32 AM, Bastien wrote:
> Hi Eric,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I think in the original discussion the patch went back and forth between
>> completing on `package-alist' and completing on `features'. The former
>> didn't offer enough, the latter offered too much.
>
> While not offering "enough", the former is already an improvement, I'd
> be in favor of implementing it.  The latter really offers too much IMO.

Yes, I've come to the same conclusion over time.

>> If we complete on `features', that's definitely an issue. I think my
>> solution in that version of the patch simply dropped the issue if the
>> Maintainer header was emacs-devel, or there was no Maintainer.
>
> Yes, it looks fine to me like this.
>
>> My pleasure -- as Dmitry notes, this might not solve the problem that
>> this thread is about, but I think it's definitely worthwhile on its own.
>
> Definitely.  What is still needed here so that you can make this change?

Here's a new version of the patch. It:

1. doesn't require a package
2. only honors the Maintainer header (not the Author header, if there's no
   Maintainer)
3. screens out "emacs.devel@gnu.org" as a Maintainer value (we
   could easily add more values to screen out)
4. uses X-Debbugs-CC instead of Cc
5. Adds a "Package:" pseudo-header

Remaining questions:

1. I've seen some reference to a X-Debbugs-Package header, is that
   honored?
2. Glenn mentioned the fact that some package maintainers might not want
   anything to do with debbugs. I'm not sure how to handle that
   situation, except manually. I suppose, if we do end up adding a
   package maintainer, we could also add a line of text in the
   intangible instructions saying, "If you don't want to deal with this
   bug on the Emacs bug tracker, please send a message to
   XXX-done@debbugs.gnu.org to close it."
3. Lastly, this is a fairly in-your-face change to how Emacs bugs are
   reported, and I'm not sure everyone agrees it's a good idea! Adding
   an extra prompt to the process is a bit intrusive.

Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Cc-package-maintainers-when-reporting-emacs-bugs.patch --]
[-- Type: text/x-patch, Size: 3644 bytes --]

From ae806f23a8e8b784ed1c18a0783c563fa013f601 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Thu, 21 Jul 2016 15:58:47 -0400
Subject: [PATCH] Cc package maintainers when reporting emacs bugs

* lisp/mail/emacsbug.el (report-emacs-bug): Prompt for a package to
  report a bug against, and cc the package maintainer, if any, on the
  bug report.
---
 lisp/mail/emacsbug.el | 32 ++++++++++++++++++++++++++++----
 1 file changed, 28 insertions(+), 4 deletions(-)

diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
index 7f3dc4454a..0a39cb682f 100644
--- a/lisp/mail/emacsbug.el
+++ b/lisp/mail/emacsbug.el
@@ -206,17 +206,30 @@ message-send-mail-function
 (defvar message-sendmail-envelope-from)
 
 ;;;###autoload
-(defun report-emacs-bug (topic &optional unused)
+(defun report-emacs-bug (topic package &optional unused)
   "Report a bug in GNU Emacs.
 Prompts for bug subject.  Leaves you in a mail buffer."
   (declare (advertised-calling-convention (topic) "24.5"))
-  (interactive "sBug Subject: ")
+  (interactive (list
+                (read-string "Bug Subject: ")
+                (completing-read
+                 "Package: "
+                 (progn
+                   (package-initialize)
+                   package-alist)
+                 nil nil)))
   ;; The syntax `version;' is preferred to `[version]' because the
   ;; latter could be mistakenly stripped by mailing software.
   (setq topic (concat emacs-version "; " topic))
   (let ((from-buffer (current-buffer))
 	(can-insert-mail (or (report-emacs-bug-can-use-xdg-email)
 			     (report-emacs-bug-can-use-osx-open)))
+        (cc (unless (or (string-empty-p package) (string= package "emacs"))
+              (require 'finder)
+              (lm-with-file (find-library-name package)
+                ;; Don't use `lm-maintainer', as that falls back on
+                ;; author.
+                (lm-header "maintainer"))))
         user-point message-end-point)
     (setq message-end-point
 	  (with-current-buffer (messages-buffer)
@@ -232,7 +245,7 @@ report-emacs-bug
     (compose-mail report-emacs-bug-address topic)
     ;; The rest of this does not execute if the user was asked to
     ;; confirm and said no.
-    (when (eq major-mode 'message-mode)
+    (when (derived-mode-p 'message-mode)
       ;; Message-mode sorts the headers before sending.  We sort now so
       ;; that report-emacs-bug-orig-text remains valid.  (Bug#5178)
       (message-sort-headers)
@@ -243,6 +256,15 @@ report-emacs-bug
       (when (and (not (message--sendmail-envelope-from))
 		 (message-bogus-recipient-p (message-make-address)))
 	(set (make-local-variable 'message-sendmail-envelope-from) 'header)))
+    (when (and cc
+               (setq cc (lm-crack-address cc))
+               (null (string= "emacs.devel@gnu.org" (cdr cc))))
+      (if (derived-mode-p 'message-mode)
+          (message-position-on-field "X-Debbugs-CC")
+        (mail-position-on-field "X-Debbugs-CC"))
+      (if (car cc)
+          (insert (format "%s <%s>" (car cc) (cdr cc)))
+        (insert (format "%s" (cdr cc)))))
     (rfc822-goto-eoh)
     (forward-line 1)
     ;; Move the mail signature to the proper place.
@@ -415,7 +437,9 @@ report-emacs-bug
     (make-local-variable 'report-emacs-bug-orig-text)
     (setq report-emacs-bug-orig-text
           (buffer-substring-no-properties (point-min) (point)))
-    (goto-char user-point)))
+    (goto-char user-point)
+    (unless (string-empty-p package)
+      (insert "Package: " package "\n\n"))))
 
 (define-obsolete-function-alias 'report-emacs-bug-info 'info-emacs-bug "24.3")
 
-- 
2.26.2

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Mon, 01 Jun 2020 11:29:14 -0700
> Cc: 41373@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>  Richard Stallman <rms@gnu.org>, dgutov@yandex.ru
> 
> +  (interactive (list
> +                (read-string "Bug Subject: ")
> +                (completing-read
> +                 "Package: "
> +                 (progn
> +                   (package-initialize)
> +                   package-alist)
> +                 nil nil)))

Does this mean reporting a bug will initialize all the packages that
are installed?  Will it also access the network and check for
upgrades?

I'm not sure I understand the need to produce a potentially huge list
of completion candidates, when it isn't even clear that the bug is
about some add-on package.  Can we be smarter about this?

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

On 06/01/20 21:41 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Mon, 01 Jun 2020 11:29:14 -0700
>> Cc: 41373@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>,
>>  Richard Stallman <rms@gnu.org>, dgutov@yandex.ru
>> 
>> +  (interactive (list
>> +                (read-string "Bug Subject: ")
>> +                (completing-read
>> +                 "Package: "
>> +                 (progn
>> +                   (package-initialize)
>> +                   package-alist)
>> +                 nil nil)))
>
> Does this mean reporting a bug will initialize all the packages that
> are installed?  Will it also access the network and check for
> upgrades?

I don't believe so, no. But we should probably call `package-initialize'
with the NO-ACTIVATE argument, which will skip loading autoloads and
some other stuff. Or, for minimum invasiveness, just skip everything if
`package-alist' is nil.

> I'm not sure I understand the need to produce a potentially huge list
> of completion candidates, when it isn't even clear that the bug is
> about some add-on package.  Can we be smarter about this?

Right, this is the part of the suggestion with the biggest question
marks. I can imagine the prompt would get annoying for frequent
contributors who are mostly filing bugs against emacs itself.

The only thing I can think of is providing a separate command,
`report-emacs-package-bug', that is a thin wrapper around
`report-emacs-bug'. That could live in package.el.

Actually, maybe that's the way to go?

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: bzg@gnu.org,  41373@debbugs.gnu.org,  stefankangas@gmail.com,
>   rms@gnu.org,  dgutov@yandex.ru
> Date: Mon, 01 Jun 2020 12:25:11 -0700
> 
> > I'm not sure I understand the need to produce a potentially huge list
> > of completion candidates, when it isn't even clear that the bug is
> > about some add-on package.  Can we be smarter about this?
> 
> Right, this is the part of the suggestion with the biggest question
> marks. I can imagine the prompt would get annoying for frequent
> contributors who are mostly filing bugs against emacs itself.
> 
> The only thing I can think of is providing a separate command,
> `report-emacs-package-bug', that is a thin wrapper around
> `report-emacs-bug'. That could live in package.el.

I thought about making some conclusions from the text of the report,
which may contain function names.  Of course, this is only possible
after the report is written and is about to be sent.

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Glenn Morris]

Eric Abrahamsen wrote:

> 5. Adds a "Package:" pseudo-header

That is not the right thing to do.
A debbugs.gnu.org package is not the same thing as an elpa.gnu.org package. [1]
The valid debbugs.gnu.org packages are listed at
https://debbugs.gnu.org/Packages.html
Trying to use one not listed there will result in the mail going to the
help-debbugs list.

Separately, you should add an "X-Debbugs-CC" pseudo-header, because it
seems some mail clients don't allow arbitrary (real) X- mail headers.

I hope this is at most restricted to elpa.gnu.org packages.
There are already thousands of open Emacs bug reports.
If reports for melpa packages start getting funnelled into the same
system, it will make it harder than it already is to find relevant reports.

(Also IMO this doesn't actually fix the issue from this bug report.
Each elpa.gnu.org package should still be defining where it wants its
bug reports to go to. This may be the maintainer address, github issue,
or whatever.)


[1] With some effort, someone could in principle automatically create an
elpa-X package on debbugs for every package X on elpa.gnu.org.

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

On 06/01/20 22:38 PM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: bzg@gnu.org,  41373@debbugs.gnu.org,  stefankangas@gmail.com,
>>   rms@gnu.org,  dgutov@yandex.ru
>> Date: Mon, 01 Jun 2020 12:25:11 -0700
>> 
>> > I'm not sure I understand the need to produce a potentially huge list
>> > of completion candidates, when it isn't even clear that the bug is
>> > about some add-on package.  Can we be smarter about this?
>> 
>> Right, this is the part of the suggestion with the biggest question
>> marks. I can imagine the prompt would get annoying for frequent
>> contributors who are mostly filing bugs against emacs itself.
>> 
>> The only thing I can think of is providing a separate command,
>> `report-emacs-package-bug', that is a thin wrapper around
>> `report-emacs-bug'. That could live in package.el.
>
> I thought about making some conclusions from the text of the report,
> which may contain function names.  Of course, this is only possible
> after the report is written and is about to be sent.

Huh, so just before sending build a regexp like:

(mapconcat
 (lambda (p)
   (format "\\_<%s-" (symbol-name (car p))))
 package-alist "\\|")

run it over the subject and body, and then either automatically add the
package header, or stop and prompt the user?

Feels a bit guess-worky to me, but it would certainly be possible!

bug#41373: GNU ELPA: Add "reporting bugs" to individual package pages

[Eric Abrahamsen]

On 06/01/20 15:52 PM, Glenn Morris wrote:
> Eric Abrahamsen wrote:
>
>> 5. Adds a "Package:" pseudo-header
>
> That is not the right thing to do.
> A debbugs.gnu.org package is not the same thing as an elpa.gnu.org package. [1]
> The valid debbugs.gnu.org packages are listed at
> https://debbugs.gnu.org/Packages.html
> Trying to use one not listed there will result in the mail going to the
> help-debbugs list.
>
> Separately, you should add an "X-Debbugs-CC" pseudo-header, because it
> seems some mail clients don't allow arbitrary (real) X- mail headers.

Thanks for this. You'd mentioned a pseudo-header in your previous
message, and all I could see defined was "Package" and "Version", so I
assumed you meant Package; my mistake.

> I hope this is at most restricted to elpa.gnu.org packages.
> There are already thousands of open Emacs bug reports.
> If reports for melpa packages start getting funnelled into the same
> system, it will make it harder than it already is to find relevant reports.

Good point. You could also argue that, by putting their packages on
Melpa, these authors have already implicitly hinted that they'd rather
not interact with the Emacs organization/infrastructure.

> (Also IMO this doesn't actually fix the issue from this bug report.
> Each elpa.gnu.org package should still be defining where it wants its
> bug reports to go to. This may be the maintainer address, github issue,
> or whatever.)

While I was succumbing to mission-creep this afternoon, I thought of the
same thing: an "Issues-to" package header. This would also give package
authors an explicit mechanism to opt out of debbugs.

> [1] With some effort, someone could in principle automatically create an
> elpa-X package on debbugs for every package X on elpa.gnu.org.

Dunno about this. I started with this idea from the point of view of an
(ELPA) package maintainer. At this point, I'm happy to just implement
whatever everyone agrees makes the most sense.

Eric