GNU bug report logs - #33225
[debbugs.el] Don't send control message immediately

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 33225 in the body.
You can then email your comments to 33225 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [debbugs.el] Don't send control message immediately
Date: Thu, 01 Nov 2018 08:29:59 -0400

[Message part 1 (text/plain, inline)]

Tags: patch
Severity: wishlist
X-Debbugs-CC: "Garreau, Alexandre" <galex-713 <at> galex-713.eu>, Michael Albinus <michael.albinus <at> gmx.de>

As mentioned in [1], I have a modified version of
debbugs-gnu-send-control-message which just creates the message (or
edits the current one) rather than sending it right away.  I'm posting
it here as a patch to debbugs-gnu.el.  It might make sense to replace
the current debbugs-gnu-send-control-message, or just factor out the
common parts, I haven't really thought much about that.

[1]: http://lists.gnu.org/archive/html/help-debbugs/2018-10/msg00014.html

[v1-0001-New-command-debbugs-control-make-message.patch (text/plain, attachment)]

Message #8 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: "Garreau\, Alexandre" <galex-713 <at> galex-713.eu>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, michael albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Thu, 01 Nov 2018 15:28:54 +0100

[Message part 1 (text/plain, inline)]

On 2018-11-01 at 08:29, Noam Postavsky wrote:
> As mentioned in [1], I have a modified version of
> debbugs-gnu-send-control-message which just creates the message (or
> edits the current one) rather than sending it right away.

I believe this is the most straightforward solution to the problem of
control messages sending too fast for the newcomer user.  However, I
guess this is a feature more than a bug for most used users, and this
would have been only useful for the first time to me, when I wanted to
“test it to see how it looks” thinking of “cancelling at the last
moment”, and discovered the mail was already sent before I could even
understand what was happening (and take the time to document more myself
on what was the control message really meaning).  Sure if I saw a
message-mode buffer before, at this moment, I’d have canceled, but that
would only have been useful the first time: then it would have become
tiring, so I would have disabled it to come back the simple behavior,
and loose the benefit of the additional security-check step.

> I'm posting it here as a patch to debbugs-gnu.el.  It might make sense
> to replace the current debbugs-gnu-send-control-message, or just
> factor out the common parts, I haven't really thought much about that.
>
> [1]: http://lists.gnu.org/archive/html/help-debbugs/2018-10/msg00014.html

What I suggested later instead was asking for confirmation for certain
control messages that might uselessly garble and bloat the bug history,
while letting go more common and useful messages that might otherwise
anyway be undone without semantic overhead [2], first suggestion was
just about asking for confirmation about certain messages and not
others, so I attach the already suggested [3] patch here for better
referencing of it.  But in last message [2] I argued in favor of better
discrimination among control messages and potentially clarifying their
meaning and better linking doc.

[debbugs-gnu_confirm-control.patch (text/x-diff, inline)]

diff --git a/packages/debbugs/debbugs-gnu.el b/packages/debbugs/debbugs-gnu.el
index 5466d6518..ea61e96bb 100644
--- a/packages/debbugs/debbugs-gnu.el
+++ b/packages/debbugs/debbugs-gnu.el
@@ -1462,6 +1462,32 @@ returned by `debbugs-gnu-bugs'."
 	       (number-sequence (string-to-number from) (string-to-number to)))
 	      result))))))))
 
+(defconst debbugs-gnu-control-messages
+  '("serious" "important" "normal" "minor" "wishlist"
+    "done" "donenotabug" "donewontfix" "doneunreproducible"
+    "unarchive" "unmerge" "reopen" "close"
+    "merge" "forcemerge"
+    "block" "unblock"
+    "owner" "noowner"
+    "forwarded" "notforwarded"
+    "invalid"
+    "reassign"
+    "retitle"
+    "patch" "wontfix" "moreinfo" "unreproducible" "fixed" "notabug"
+    "pending" "help" "security" "confirmed" "easy"
+    "usertag")
+  "List of control messages accepted by Debbugs.
+All are accepted and processed by `debbugs-gnu-send-control-message'
+accordingly.")
+
+(defcustom debbugs-gnu-confirm-control-messages '("owner")
+  "List of control messages asking for confirmation.
+Each message listed will make `debbugs-gnu-send-control-message'
+ask for confirmation before sending control message mail."
+  :type (cons 'set (mapcar (apply-partially #'list 'const)
+                           debbugs-gnu-control-messages))
+  :group 'debbugs-gnu)
+
 (defun debbugs-gnu-send-control-message (message &optional reverse)
   "Send a control message for the current bug report.
 You can set the severity or add a tag, or close the report.  If
@@ -1473,19 +1499,7 @@ removed instead."
   (interactive
    (list (completing-read
 	  "Control message: "
-	  '("serious" "important" "normal" "minor" "wishlist"
-	    "done" "donenotabug" "donewontfix" "doneunreproducible"
-	    "unarchive" "unmerge" "reopen" "close"
-	    "merge" "forcemerge"
-	    "block" "unblock"
-	    "owner" "noowner"
-	    "forwarded" "notforwarded"
-	    "invalid"
-	    "reassign"
-	    "retitle"
-	    "patch" "wontfix" "moreinfo" "unreproducible" "fixed" "notabug"
-	    "pending" "help" "security" "confirmed" "easy"
-	    "usertag")
+	  debbugs-gnu-control-messages
 	  nil t)
 	 current-prefix-arg))
   (let* ((id (or (debbugs-gnu-current-id t)
@@ -1585,11 +1599,14 @@ removed instead."
 		(format "tags %d%s %s\n"
 			id (if reverse " -" "")
 			message))))
-      (funcall (or debbugs-gnu-send-mail-function send-mail-function))
-      (remhash id debbugs-cache-data)
-      (message-goto-body)
-      (message "Control message sent:\n%s"
-	       (buffer-substring-no-properties (point) (1- (point-max)))))))
+      (unless (and (member message debbugs-gnu-confirm-control-messages)
+                   (not (y-or-n-p (format "Really send `%s' control message? "
+                                          message))))
+        (funcall (or debbugs-gnu-send-mail-function send-mail-function))
+        (remhash id debbugs-cache-data)
+        (message-goto-body)
+        (message "Control message sent:\n%s"
+                 (buffer-substring-no-properties (point) (1- (point-max))))))))
 
 (defvar debbugs-gnu-usertags-mode-map
   (let ((map (make-sparse-keymap)))

[Message part 3 (text/plain, inline)]

[2] http://lists.gnu.org/archive/html/help-debbugs/2018-11/msg00006.html
[3] http://lists.gnu.org/archive/html/help-debbugs/2018-11/msg00001.html

Message #11 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Fri, 02 Nov 2018 11:23:03 +0100

Noam Postavsky <npostavs <at> gmail.com> writes:

Hi Noam,

> As mentioned in [1], I have a modified version of
> debbugs-gnu-send-control-message which just creates the message (or
> edits the current one) rather than sending it right away.  I'm posting
> it here as a patch to debbugs-gnu.el.

Looks interesting. It seems better suited to extend existing messages,
when replying to another bug-related message.

However, when I call it interactively for control message
"documentation", I get an error:

save-excursion: Search failed: "^user emacs$"

Maybe you could fix it? Furthermore, it asks me for the bug id, even if
the Cc: header contains already such. I guess it could retrieve this
there, and show me as default if it is unique.

> It might make sense to replace the current
> debbugs-gnu-send-control-message, or just factor out the common parts,
> I haven't really thought much about that.

I believe we should keep both functions (with a common basic function),
with different key bindings. "C" for debbugs-gnu-send-control-message,
and maybe "E" for debbugs-control-make-message.

I like also your extensions of the control messages. Would you like to
document them in debbugs-ug.texi?

Best regards, Michael.

Message #14 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: "Garreau\, Alexandre" <galex-713 <at> galex-713.eu>
Cc: 33225 <at> debbugs.gnu.org, Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Fri, 02 Nov 2018 11:30:10 +0100

"Garreau, Alexandre" <galex-713 <at> galex-713.eu> writes:

Hi Alexandre,

>> As mentioned in [1], I have a modified version of
>> debbugs-gnu-send-control-message which just creates the message (or
>> edits the current one) rather than sending it right away.
>
> I believe this is the most straightforward solution to the problem of
> control messages sending too fast for the newcomer user.

As you have seen the other message, I'm also in favor of this solution.

> However, I guess this is a feature more than a bug for most used
> users, and this would have been only useful for the first time to me,
> when I wanted to “test it to see how it looks” thinking of “cancelling
> at the last moment”, and discovered the mail was already sent before I
> could even understand what was happening (and take the time to
> document more myself on what was the control message really meaning).
> Sure if I saw a message-mode buffer before, at this moment, I’d have
> canceled, but that would only have been useful the first time: then it
> would have become tiring, so I would have disabled it to come back the
> simple behavior, and loose the benefit of the additional
> security-check step.

In fact I believe we shall offer both
functions. debbugs-gnu-send-control-message, without any confirmation,
is good for experienced users. When you are working on a bug triage, for
example, you need a fluid workflow, w/o interruption for confirmation
and alike.

> What I suggested later instead was asking for confirmation for certain
> control messages that might uselessly garble and bloat the bug history,
> while letting go more common and useful messages that might otherwise
> anyway be undone without semantic overhead [2], first suggestion was
> just about asking for confirmation about certain messages and not
> others, so I attach the already suggested [3] patch here for better
> referencing of it.  But in last message [2] I argued in favor of better
> discrimination among control messages and potentially clarifying their
> meaning and better linking doc.

I believe it is a matter of personal taste, which control messages need
a confirmation, and which not. And this will change also over the
time. Oce you know what "owner" is intended for, you don't need to
confirm this again and again.

What I could imagine is, that you implement an explanation for the
control messages, based on Noam's debbugs-control-make-message. This
needs an emhancement in the manuals, but I'm working on.

Best regards, Michael.

Message #17 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Fri, 04 Jan 2019 15:38:31 +0100

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

Hi Noam,

>> As mentioned in [1], I have a modified version of
>> debbugs-gnu-send-control-message which just creates the message (or
>> edits the current one) rather than sending it right away.  I'm posting
>> it here as a patch to debbugs-gnu.el.
>
> Looks interesting. It seems better suited to extend existing messages,
> when replying to another bug-related message.
>
> However, when I call it interactively for control message
> "documentation", I get an error:
>
> save-excursion: Search failed: "^user emacs$"
>
> Maybe you could fix it? Furthermore, it asks me for the bug id, even if
> the Cc: header contains already such. I guess it could retrieve this
> there, and show me as default if it is unique.
>
>> It might make sense to replace the current
>> debbugs-gnu-send-control-message, or just factor out the common parts,
>> I haven't really thought much about that.
>
> I believe we should keep both functions (with a common basic function),
> with different key bindings. "C" for debbugs-gnu-send-control-message,
> and maybe "E" for debbugs-control-make-message.
>
> I like also your extensions of the control messages. Would you like to
> document them in debbugs-ug.texi?

This is lying around. Do you plan to commit it to elpa? If not, what do
you want to do with this?

Best regards, Michael.

Message #20 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Wed, 27 Feb 2019 09:45:51 +0100

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

> This is lying around. Do you plan to commit it to elpa? If not, what do
> you want to do with this?

Ping.

Best regards, Michael.

Message #23 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Wed, 27 Feb 2019 20:10:44 -0500

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

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> This is lying around. Do you plan to commit it to elpa? If not, what do
>> you want to do with this?
>
> Ping.

Hi, I've been on break from Emacs development for personal reasons, but
I do plan on getting this cleaned up and committed within the next few
weeks.

Message #26 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Thu, 28 Feb 2019 08:10:31 +0100

Noam Postavsky <npostavs <at> gmail.com> writes:

Hi Noam,

> Hi, I've been on break from Emacs development for personal reasons, but

Yes, I was missing you ...

> I do plan on getting this cleaned up and committed within the next few
> weeks.

Thanks!

Best regards, Michael.

Message #29 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Fri, 29 Mar 2019 22:43:37 -0400

[Message part 1 (text/plain, inline)]

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

>> As mentioned in [1], I have a modified version of
>> debbugs-gnu-send-control-message which just creates the message (or
>> edits the current one) rather than sending it right away.  I'm posting
>> it here as a patch to debbugs-gnu.el.
>
> Looks interesting. It seems better suited to extend existing messages,
> when replying to another bug-related message.

Yes, though it can also be used to make a control message with more than
one command in it.  And I personally find the way
debbugs-gnu-send-control-message sends the message right away without
even any chance to inspect or modify it rather uncomfortable.  I guess
I'm a bit of a control freak. ;)

> However, when I call it interactively for control message
> "documentation", I get an error:
>
> save-excursion: Search failed: "^user emacs$"
>
> Maybe you could fix it?

Oops, that was a silly mistake.  I didn't end up using the documentation
tag very much.  Obviously not well-tested.

> Furthermore, it asks me for the bug id, even if
> the Cc: header contains already such. I guess it could retrieve this
> there, and show me as default if it is unique.

Ah, it already puts the inferred bug id as default input, but the prompt
doesn't show it.  I use ido completion, which shows the default already
as a completion candidate, so I didn't notice that.  I've added it to
the prompt now.

>> It might make sense to replace the current
>> debbugs-gnu-send-control-message, or just factor out the common parts,
>> I haven't really thought much about that.
>
> I believe we should keep both functions (with a common basic function),
> with different key bindings. "C" for debbugs-gnu-send-control-message,
> and maybe "E" for debbugs-control-make-message.

Okay.  I think debbugs-gnu-make-control-message can be the common basic
function.

> I like also your extensions of the control messages. Would you like to
> document them in debbugs-ug.texi?

Added, though it looks like the .info file is also in git?  I haven't
regenerated it since I use texinfo 4.13, so that would trigger all sorts
of spurious changes.

[v2-0001-New-command-debbugs-control-make-message-Bug-3322.patch (text/plain, attachment)]

Message #32 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Sun, 31 Mar 2019 12:21:29 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

Hi Noam,

Thanks for the patch. In general, it works fine, so I guess you could
push it. We (I)'ll play then for some days, and if there's no serious
complaint, I'll make a new debbugs release.

But I still have some comments :-)

Please rename

debbugs-control-make-message → debbugs-gnu-make-control-message
debbugs-control-message-keywords → debbugs-gnu-control-message-keywords
debbugs-control-message-commands-regexp → debbugs-gnu-control-message-commands-regexp
debbugs-control-message-end-regexp → debbugs-gnu-control-message-end-regexp

Please add (the keybindings of) debbugs-gnu-make-control-message to the
Commentary sections of debbugs-gnu.el and debbugs-org.el and to the nodes
"Tabulated Lists" and "TODO Items" of debbugs-ug.texi.

Compiling debbugs-gnu.el results in

debbugs-gnu.el:1534:1:Warning: Unused lexical variable ‘addr’
debbugs-gnu.el:1552:1:Warning: Unused lexical variable ‘micro’
debbugs-gnu.el:1552:1:Warning: Unused lexical variable ‘subject’

Maybe you can fix it?

> Added, though it looks like the .info file is also in git?  I haven't
> regenerated it since I use texinfo 4.13, so that would trigger all sorts
> of spurious changes.

Yes, unfortunately, the info file must be there. Don't worry about, I'll
regenerate.

> +(defconst debbugs-control-message-keywords
> +  '("serious" "important" "normal" "minor" "wishlist"
> +    "done" "donenotabug" "donewontfix" "doneunreproducible"
> +    "invalid" ; done+notabug+wontfix
> +    "unarchive" "unmerge" "reopen" "close"
> +    "merge" "forcemerge"
> +    "block" "unblock"
> +    "owner" "noowner"
> +    "reassign"
> +    "retitle"
> +    "forwarded" "notforwarded"
> +    ;; 'notfixed <bugnum> <version>' works, even though it's
> +    ;; undocumented at debbugs.gnu.org.
> +    "fixed" "found" "notfound" "notfixed"
> +    "patch" "wontfix" "moreinfo" "unreproducible" "notabug"
> +    "pending" "help" "security" "confirmed" "easy"
> +    "usertag" "user"
> +    "documentation" ;; usertag:emacs.documentation
> +    ))

I suppose "user" is needed in case of debbugs-gnu-make-control-message
only. Could we separate this, and offer completion only for that
function?

> +        ((member message '("merge" "forcemerge"))
> +         (format "%s %d %s\n" message bugid
> +                 (read-string "Merge with bug #: ")))

You have removed the bug number completion via
debbugs-gnu-expand-bug-number-list. Why?

> +        ((member message '("block" "unblock"))
> +         (format
> +          "%s %d by %s\n" message bugid
> +          (mapconcat
> +           'identity
> +           (completing-read-multiple
> +            (format "%s with bug(s) #: " (capitalize message))
> +            (if (equal message "unblock")
> +                (mapcar 'number-to-string
> +                        (cdr (assq 'blockedby status))))
> +            nil (and (equal message "unblock") status))
> +           " ")))

dito

> +@item user
> +"user @var{username}"
> +
> +The username, read interactively, is either a package name or an email
> +address.

Please mention, that this is used in order to avoid giving the user name
again, for further commands.

Best regards, Michael.

Message #35 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Sun, 31 Mar 2019 17:27:27 -0400

[Message part 1 (text/plain, inline)]

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

> Thanks for the patch. In general, it works fine, so I guess you could
> push it. We (I)'ll play then for some days, and if there's no serious
> complaint, I'll make a new debbugs release.
>
> But I still have some comments :-)

I've updated according to your comments, I'll wait another couple of
days before pushing in case we can catch any more silly mistakes.

Regarding making a release, I have in mind next to bring in my commands
which produce control messages from git commits (both for attaching
proposed patches from an unpushed commit, and closing from a pushed
one).  Perhaps you want to wait for that before making a new release?
(or perhaps just the opposite, not sure what your release policy is)

> Please rename
>
> debbugs-control-make-message → debbugs-gnu-make-control-message
> debbugs-control-message-keywords → debbugs-gnu-control-message-keywords
> debbugs-control-message-commands-regexp → debbugs-gnu-control-message-commands-regexp
> debbugs-control-message-end-regexp → debbugs-gnu-control-message-end-regexp
>
> Please add (the keybindings of) debbugs-gnu-make-control-message to the
> Commentary sections of debbugs-gnu.el and debbugs-org.el and to the nodes
> "Tabulated Lists" and "TODO Items" of debbugs-ug.texi.

Done and done.

> Compiling debbugs-gnu.el results in
>
> debbugs-gnu.el:1534:1:Warning: Unused lexical variable ‘addr’
> debbugs-gnu.el:1552:1:Warning: Unused lexical variable ‘micro’
> debbugs-gnu.el:1552:1:Warning: Unused lexical variable ‘subject’
>
> Maybe you can fix it?

Oops, yes.

>> +(defconst debbugs-control-message-keywords

>> +    "usertag" "user"
>> +    "documentation" ;; usertag:emacs.documentation
>> +    ))
>
> I suppose "user" is needed in case of debbugs-gnu-make-control-message
> only. Could we separate this, and offer completion only for that
> function?

Actually, thinking about it, there's really no need for a "user" control
message.  I've just removed it instead (it only needs to go in
debbugs-gnu-control-message-commands-regexp).

>> +        ((member message '("merge" "forcemerge"))
>> +         (format "%s %d %s\n" message bugid
>> +                 (read-string "Merge with bug #: ")))
>
> You have removed the bug number completion via
> debbugs-gnu-expand-bug-number-list. Why?

>> +        ((member message '("block" "unblock"))

> dito

Ah, I think what happened is that I started from a very old version
debbugs-gnu-send-control-message which didn't use
debbugs-gnu-expand-bug-number-list.  Fixed now (I also added back the
version arg to "close").

>> +@item user
>> +"user @var{username}"
>> +
>> +The username, read interactively, is either a package name or an email
>> +address.
>
> Please mention, that this is used in order to avoid giving the user name
> again, for further commands.

As mentioned above, I decided to simply remove this instead.  And I also
removed the duplicate avoidance feature of "documentation".  Making the
message shorter isn't that much of a benefit, and having it adds more
possible failure modes (e.g., if there is both "user emacs" and "user
something-else", things get tricky).

[v3-0001-New-command-debbugs-control-make-message-Bug-3322.patch (text/plain, attachment)]

Message #38 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Mon, 01 Apr 2019 09:35:45 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

Hi Noam,

> I've updated according to your comments, I'll wait another couple of
> days before pushing in case we can catch any more silly mistakes.

It looks almost good. Still some minor nits :-)

> Regarding making a release, I have in mind next to bring in my commands
> which produce control messages from git commits (both for attaching
> proposed patches from an unpushed commit, and closing from a pushed
> one).  Perhaps you want to wait for that before making a new release?
> (or perhaps just the opposite, not sure what your release policy is)

My release policy is very simple: gut feeling. I have no pending issue
to solve, so we could wait for the release.

I'd prefer if you would commit your changes so far, that we have a
common base, and further patches you'll show are shorter (to review).

> +        ((member message '("unarchive" "unmerge" "noowner"
> +                           "notfixed" "notforwarded"))
> +         (format "%s %d\n" message bugid))

You have (correctly) said, that "notfixed" isn't documented on
debbugs.gnu.org. So I have checked
<https://www.debian.org/Bugs/server-control#notfixed>. "notfixed"
requires also a version number, it should be moved to the handling of

> +        ((member message '("found" "notfound" "fixed"))
> +         (format "%s %d %s\n" message bugid version))

> +@item
> +@kindex @kbd{C}
> +@kbd{C} @tab
> +@code{debbugs-gnu-make-control-message} @*


This shall be {E}

> +@item found
> +@itemx notfound
> +@itemx fixed
> +"found|notfound|fixed 12345 25.1"

Please add notfixed.

Best regards, Michael.

Message #41 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Mon, 01 Apr 2019 09:34:17 -0400

[Message part 1 (text/plain, inline)]

Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> Regarding making a release, I have in mind next to bring in my commands
>> which produce control messages from git commits (both for attaching
>> proposed patches from an unpushed commit, and closing from a pushed
>> one).  Perhaps you want to wait for that before making a new release?
>> (or perhaps just the opposite, not sure what your release policy is)
>
> My release policy is very simple: gut feeling. I have no pending issue
> to solve, so we could wait for the release.
>
> I'd prefer if you would commit your changes so far, that we have a
> common base, and further patches you'll show are shorter (to review).

Yes, I would open a new bug thread for the feature I mention above,
after this is one is closed and pushed.

>> +        ((member message '("unarchive" "unmerge" "noowner"
>> +                           "notfixed" "notforwarded"))
>> +         (format "%s %d\n" message bugid))
>
> You have (correctly) said, that "notfixed" isn't documented on
> debbugs.gnu.org. So I have checked
> <https://www.debian.org/Bugs/server-control#notfixed>. "notfixed"
> requires also a version number [...]

Huh, indeed.  Not sure how I messed that up.  I even have it correct in
my .emacs.d/, so it seems something went wrong while moving it to
debbugs-gnu.el.

>> +@item
>> +@kindex @kbd{C}
>> +@kbd{C} @tab
>> +@code{debbugs-gnu-make-control-message} @*
>
>
> This shall be {E}

Right.

>> +@item found
>> +@itemx notfound
>> +@itemx fixed
>> +"found|notfound|fixed 12345 25.1"
>
> Please add notfixed.

Done.  Hmm, I just noticed that we have "@itemx fixed" in two places.
So there is a conflict between "fixed" as a tag, and "fixed" as its own
command.  I think the command should precedence (that was already the
case in the code for previous patches, now I've updated the doc as
well).

One last thing I noticed when byte-compiling from emacs -Q, is that I
needed to add a couple of autoloads for the message functions.  And then
I realized that the message-narrow-to-head call should actually be
message-narrow-to-headers, since the latter looks for
mail-header-separator, while the former just looks for a blank line (in
practice, it doesn't make much difference unless the message body
happens to have text that looks like a mail header).

[v4-0001-New-command-debbugs-control-make-message-Bug-3322.patch (text/plain, attachment)]

Message #44 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Mon, 01 Apr 2019 16:52:17 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

Hi Noam,

>> I'd prefer if you would commit your changes so far, that we have a
>> common base, and further patches you'll show are shorter (to review).
>
> Yes, I would open a new bug thread for the feature I mention above,
> after this is one is closed and pushed.

OK.

>>> +@item found
>>> +@itemx notfound
>>> +@itemx fixed
>>> +"found|notfound|fixed 12345 25.1"
>>
>> Please add notfixed.
>
> Done.  Hmm, I just noticed that we have "@itemx fixed" in two places.
> So there is a conflict between "fixed" as a tag, and "fixed" as its own
> command.  I think the command should precedence (that was already the
> case in the code for previous patches, now I've updated the doc as
> well).

OK.

> One last thing I noticed when byte-compiling from emacs -Q, is that I
> needed to add a couple of autoloads for the message functions.  And then
> I realized that the message-narrow-to-head call should actually be
> message-narrow-to-headers, since the latter looks for
> mail-header-separator, while the former just looks for a blank line (in
> practice, it doesn't make much difference unless the message body
> happens to have text that looks like a mail header).

That was also on my todo list. I'm glad if you fix it (but, as finical
German, I prefer to insert them in alphabetical order).

There's nothing left I could nitpick, so pls commit :-)

Thanks, and best regards, Michael.

Message #47 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Mon, 01 Apr 2019 18:47:28 -0400

tags 33225 fixed
close 33225
quit

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

> That was also on my todo list. I'm glad if you fix it (but, as finical
> German, I prefer to insert them in alphabetical order).
>
> There's nothing left I could nitpick, so pls commit :-)

Okay, sorted and pushed.

[1: be4e402f9]: 2019-04-01 18:45:04 -0400
  New command debbugs-control-make-message (Bug#33225)
  https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=be4e402f92ba3c2326f0f71afdcc5dde66546624

Message #54 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Mon, 01 Apr 2019 18:59:59 -0400

>> There's nothing left I could nitpick, so pls commit :-)
>
> Okay, sorted and pushed.
>
> [1: be4e402f9]: 2019-04-01 18:45:04 -0400
>   New command debbugs-control-make-message (Bug#33225)
>   https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=be4e402f92ba3c2326f0f71afdcc5dde66546624

Ugh, of course I discover a mistake just after pushing (in fact, while
using it to create the previous message).  I forgot to check for a nil
version in a couple of cases.

[2: 54678808c]: 2019-04-01 18:54:10 -0400
  Fix previous change for version-less commands
  https://git.savannah.gnu.org/cgit/emacs/elpa.git/commit/?id=54678808cdb18da080553e18ce5d806cd1659c82

Message #57 received at 33225 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 33225 <at> debbugs.gnu.org, "garreau, alexandre" <galex-713 <at> galex-713.eu>
Subject: Re: bug#33225: [debbugs.el] Don't send control message immediately
Date: Tue, 02 Apr 2019 07:52:29 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

> Okay, sorted and pushed.

Thanks!

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.