[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#33225: [debbugs.el] Don't send control message immediately
From: |
Noam Postavsky |
Subject: |
bug#33225: [debbugs.el] Don't send control message immediately |
Date: |
Mon, 01 Apr 2019 09:34:17 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1.91 (gnu/linux) |
Michael Albinus <michael.albinus@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
Description: patch