Our use of the "fixed" tag in debbugs

Our use of the "fixed" tag in debbugs

[Stefan Kangas]

We currently use the debbugs "fixed" tag almost exclusively in this way:

    tags NNN fixed
    close NNN 29.1
    thanks

This is fine by me, no change needed here.  There is a slight
duplication in that we say that it's fixed twice, but that's minor.

But I note that the developer documentation says that "fixed" actually
means something slightly different:

    This bug is fixed or worked around, but there's still an issue that
    needs to be resolved.

    https://debbugs.gnu.org/Developer.html#tags

I think we could use this meaning of the "fixed" tag more often.  As
with any tag, it allows us to be a bit more granular with the bug status
than the binary "open bug" or "closed bug".

For example, I just tagged Bug#50985 ("Merging gnulib for Emacs 28.1?")
as "fixed".

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50985

The idea here is that, yes, the issue is mainly taken care of but let's
wait with closing it until we feel more confident about the fallout.

Using this tag would also make it easier to find later, so that we can
go back and see that everything is taken care of, and then close it.
Currently, bugs are unfortunately just left open and untagged, which
means that it can take a long time before someone goes back, tediously
re-reads everything, and then closes it.  Using this tag more often
could save quite a bit of time, I hope.

Re: Our use of the "fixed" tag in debbugs

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> We currently use the debbugs "fixed" tag almost exclusively in this way:
>
>     tags NNN fixed
>     close NNN 29.1
>     thanks
>
> This is fine by me, no change needed here.

debbugs-gnu just sends "close NNN 29.1" now, I think?  It was changed in:

commit 5c4039534609603e279c42e1ea390308559fce37
Author:     Michael Albinus <michael.albinus@gmx.de>
AuthorDate: Mon Apr 19 16:22:21 2021 +0200

    Don't set tag "fixed"

Because of this:

> There is a slight
> duplication in that we say that it's fixed twice, but that's minor.
>
> But I note that the developer documentation says that "fixed" actually
> means something slightly different:
>
>     This bug is fixed or worked around, but there's still an issue that
>     needs to be resolved.
>
>     https://debbugs.gnu.org/Developer.html#tags

[...]

> For example, I just tagged Bug#50985 ("Merging gnulib for Emacs 28.1?")
> as "fixed".
>
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50985
>
> The idea here is that, yes, the issue is mainly taken care of but let's
> wait with closing it until we feel more confident about the fallout.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Our use of the "fixed" tag in debbugs

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> debbugs-gnu just sends "close NNN 29.1" now, I think?

That's good.  Then I guess this should just be taken a general request
to please consider using the "fixed" tag where it makes sense.

Re: Our use of the "fixed" tag in debbugs

[Glenn Morris]

Stefan Kangas wrote:

> We currently use the debbugs "fixed" tag almost exclusively in this way:
>
>     tags NNN fixed
>     close NNN 29.1
>     thanks
>
> This is fine by me, no change needed here.

Personally I think this is a misuse of the tag, which I have
tried to discourage in https://debbugs.gnu.org/47854, and have actually
been meaning to discourage again. :)
I don't know why some Emacs developers use the tag in this way.

> For example, I just tagged Bug#50985 ("Merging gnulib for Emacs 28.1?")
> as "fixed".
>
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50985
>
> The idea here is that, yes, the issue is mainly taken care of but let's
> wait with closing it until we feel more confident about the fallout.

Personally I wish people would just be more proactive in closing things
when they believe they are fixed. It's easily reversible if needed;
unless someone has used the fixed tag! :)

> Currently, bugs are unfortunately just left open and untagged, which
> means that it can take a long time before someone goes back, tediously
> re-reads everything, and then closes it.

IMO this is just people failing to close a bug, so I don't see that they
would be any more likely to tag it. Unless for some reason people are
afraid of closing things.

But of course having said all that people doing the work (which doesn't
include me) are free to use the system however they find best.

Re: Our use of the "fixed" tag in debbugs

[Basil L. Contovounesios]

Stefan Kangas [2021-10-05 13:27 -0400] wrote:

> We currently use the debbugs "fixed" tag almost exclusively in this way:
>
>     tags NNN fixed
>     close NNN 29.1
>     thanks

I can't find the discussion now, but FWIW this was recognised as a
problem and fixed earlier this year:
https://git.sv.gnu.org/cgit/emacs/elpa.git/commit/?id=5c40395346

-- 
Basil

Re: Our use of the "fixed" tag in debbugs

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 5 Oct 2021 13:27:04 -0400
> 
> Currently, bugs are unfortunately just left open and untagged, which
> means that it can take a long time before someone goes back, tediously
> re-reads everything, and then closes it.  Using this tag more often
> could save quite a bit of time, I hope.

Tagging is tedious: you need to BCC the control address, you need to
type the line without making a mistake, etc.  It's so much easier to
just close the bug.

I'm not sure I understand what will tagging as "fixed" without closing
will gain us, can you explain?

As for closing, as long as people start arguing with us why did we
close without resolving the way they thought we should, I will leave
bugs open, because I don't have enough time for these arguments.

Re: Our use of the "fixed" tag in debbugs

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> Currently, bugs are unfortunately just left open and untagged, which
>> means that it can take a long time before someone goes back, tediously
>> re-reads everything, and then closes it.  Using this tag more often
>> could save quite a bit of time, I hope.
>
> Tagging is tedious: you need to BCC the control address, you need to
> type the line without making a mistake, etc.  It's so much easier to
> just close the bug.

Indeed, it's a hassle.  Perhaps it would help to have a command for this
in `message-mode' much like `debbugs-gnu-make-control-message'?  Or
perhaps such a thing already exist?

> I'm not sure I understand what will tagging as "fixed" without closing
> will gain us, can you explain?

Tagging is not better than closing.  It is an alternative, if we don't
yet feel confident enough to close it.

Like Glenn, I would urge people to close bugs as well.  Don't think
twice, just do it.  We have thirty days to change our mind before it is
archived.

I have closed many, many dozens of bugs where the only remaining step
was to close it.  It takes extra time after the fact, since you have to
re-read potentially very long threads, scour our git log to see if this
or that patch was applied, and so on.  And the risk of losing track of
any important information pales in comparison to the effort it takes to
go back and close bugs.  It's not a very effective use of our resources.

Of course, some people will go write Reddit or HN threads about how we
are all horrible people, but that's just par for the course.

> As for closing, as long as people start arguing with us why did we
> close without resolving the way they thought we should, I will leave
> bugs open, because I don't have enough time for these arguments.

I feel your pain.  I'm not sure that there are any easy solutions to
frivolous follow-ups, besides answering very briefly or not at all.

OTOH, this is exactly where adding a tag could be easier; and helps
someone like me to find and close it later.

Re: Our use of the "fixed" tag in debbugs

[Stefan Monnier]

> Indeed, it's a hassle.  Perhaps it would help to have a command for this
> in `message-mode' much like `debbugs-gnu-make-control-message'?  Or
> perhaps such a thing already exist?

FWIW, I use a hackish completion table for that.


        Stefan


diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index b08d8c26c9a..7cb6842f783 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -3174,7 +3181,8 @@ message-mode
    ((message-mail-alias-type-p 'ecomplete)
     (ecomplete-setup)))
   ;; FIXME: merge the completion tables from ecomplete/bbdb/...?
-  ;;(add-hook 'completion-at-point-functions #'message-ecomplete-capf nil t)
+  (add-hook 'completion-at-point-functions #'message-ecomplete-capf nil t)
+  (add-hook 'completion-at-point-functions #'message-debbugs-completion nil t)
   (add-hook 'completion-at-point-functions #'message-completion-function nil t)
   (unless buffer-file-name
     (message-set-auto-save-file-name))
@@ -8285,6 +8293,104 @@ message-completion-function
               ;; function that prevents trying any further.
               (lambda () 'completion-attempted))))))))
 
+(defun message-debbugs-completion ()
+  (save-excursion
+    (let* ((severities '("critical" "grave" "serious" "important" "normal"
+                         "minor" "wishlist"))
+           (tags '("patch" "wontfix" "moreinfo" "unreproducible"
+                   "notabug"  "fixed"))
+           (start (prog1 (point-marker)
+                    (rfc822-goto-eoh)
+                    (forward-line 1)))
+           ;; Check whether we're sending to the control address as well.
+           (control (save-excursion
+                      (re-search-backward "\\<control@" nil t)))
+           ;; Fetch current bug number, if any.
+           (bugnb (save-excursion
+                    (when (re-search-backward "^\\(?:[Ss]ubject:.*bug#\\([1-9][0-9]+\\)\\|\\(?:to\\|cc\\):\\(.*,\\)? *\\(?1:[1-9][0-9]+\\)@\\)"
+                                                nil t)
+                        (match-string 1)))))
+      ;; Add the control header as a side-effect.
+      ;; This is very handy when you want it, but it's a pain when you did not
+      ;; intend it at all, so only do it in very few circumstances to reduce
+      ;; the false positives.
+      (when (and (not control)
+                 bugnb
+                 (= (point) start))
+        (save-excursion
+          (let ((host (and (re-search-backward "^\\(?:to\\|cc\\):\\(?:.*,\\)? *<?[1-9][0-9]+@\\([a-z.]+\\)"
+                                               nil t)
+                           (match-string 1))))
+            (when host
+              (if (not (re-search-backward "^[Bb]cc:.*\\(\n[ \t].*\\)*" nil t))
+                  (progn
+                    (goto-char (point-min))
+                    (insert "Bcc: control@" host "\n"))
+                (goto-char (match-end 0))
+                (insert ", control@" host))
+              (setq control t)))))
+      ;; Check whether we're inside the "pseudo header".
+      (when (and (<= (point) start)     ;Not in the header.
+                 (save-excursion
+                   (if control
+                       (re-search-forward "^thanks\\|^[ \t]*$" nil 'move)
+                     (save-restriction
+                       (narrow-to-region (point) (point-max))
+                       (rfc822-goto-eoh)))
+                   (>= (line-end-position) start)))
+        (goto-char start)
+        (skip-chars-backward "^ \t\n:")
+        (cond
+         ((and (bolp) control)          ; Completing control commands.
+          (let ((commands '("reassign" "reopen" "found" "notfound" "submitter"
+                            "forwarded" "notforwarded" "retitle" "severity"
+                            "clone" "merge" "forcemerge" "unmerge" "tags"
+                            "block" "unblock" "owner" "noowner" "archive"
+                            "unarchive" "close")))
+            (list (point)
+                  (progn (skip-chars-forward "^ \t\n") (point))
+                  `("thanks" "package "
+                    ,@(mapcar (if bugnb
+                                  (lambda (s) (concat s " " bugnb " "))
+                                (lambda (s) (concat s " ")))
+                              commands)))))
+
+         (control                       ; Completing control command arguments.
+          (let* ((command (save-excursion
+                            (beginning-of-line)
+                            (looking-at "[^ \n\t]*")
+                            (match-string 0)))
+                 (table
+                  (cond
+                   ((equal command "severity") severities)
+                   ((equal command "tags")
+                    (let ((p (if (looking-at "-")
+                                 (match-string 0))))
+                      (mapcar (lambda (tag) (concat p tag)) tags))))))
+            (when table
+              (list (point)
+                    (progn (skip-chars-forward "^ \t\n") (point))
+                    table))))
+
+         ((bolp)                      ; Completing special pseudo-header names.
+            (list (point)
+                  (progn (skip-chars-forward "^: \t\n")
+                         (if (eq (char-after) ?:)
+                             (1+ (point)) (point)))
+                  '("Package:" "Version:" "Severity:")))
+         (t                             ; Completing a pseudo-header.
+          (let* ((header (save-excursion
+                           (beginning-of-line)
+                           (looking-at "[^ \t\n:]*:?")
+                           (match-string 0)))
+                 (table
+                  (cond
+                   ((equal header "Severity:") severities))))
+            (when table
+              (list (point)
+                    (progn (skip-chars-forward "^ \t\n") (point))
+                    table)))))))))
+
 (defun message-expand-group ()
   "Expand the group name under point."
   (let ((b (save-excursion

Re: Our use of the "fixed" tag in debbugs

[Robert Pluim]

>>>>> On Tue, 5 Oct 2021 15:44:08 -0400, Stefan Kangas <stefan@marxist.se> said:

    Stefan> Eli Zaretskii <eliz@gnu.org> writes:
    >>> Currently, bugs are unfortunately just left open and untagged, which
    >>> means that it can take a long time before someone goes back, tediously
    >>> re-reads everything, and then closes it.  Using this tag more often
    >>> could save quite a bit of time, I hope.
    >> 
    >> Tagging is tedious: you need to BCC the control address, you need to
    >> type the line without making a mistake, etc.  It's so much easier to
    >> just close the bug.

    Stefan> Indeed, it's a hassle.  Perhaps it would help to have a command for this
    Stefan> in `message-mode' much like `debbugs-gnu-make-control-message'?  Or
    Stefan> perhaps such a thing already exist?

I have a keybinding that does:

     (re-search-forward "[Bb]ug#[0-9]" nil t)
     (call-interactively #'gnus-read-ephemeral-bug-group)
     (debbugs-gnu-summary-mode 1)

You can then do 'C' and 'E' to send/make control messages.

Hmm, it might even work to just do

(debbugs-gnu-summary-mode)

when reading the debbugs list, rather than having to create the
ephemeral group for a specific bug.

Robert
-- 

Re: Our use of the "fixed" tag in debbugs

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 5 Oct 2021 13:27:04 -0400
> 
> We currently use the debbugs "fixed" tag almost exclusively in this way:
> 
>     tags NNN fixed
>     close NNN 29.1
>     thanks
> 
> This is fine by me, no change needed here.  There is a slight
> duplication in that we say that it's fixed twice, but that's minor.

Btw, "close NNN XX.YY" doesn't mark the bug as "done", see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51029#8 as one example.
This is a problem, because the fact the bug was closed isn't visible
when looking at the first screen of what the browser shows when you
display the bug.

So I think using "close" instead of NNN-done@debbugs.gnu.org should be
discouraged.

Re: Our use of the "fixed" tag in debbugs

[Basil L. Contovounesios]

Eli Zaretskii [2021-10-08 14:21 +0300] wrote:

> Btw, "close NNN XX.YY" doesn't mark the bug as "done", see

WFM: https://bugs.gnu.org/51076#11

> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51029#8 as one example.

That bug was later reopened in https://bugs.gnu.org/51029#16.

But I feel like I've run into a "closed but not done" issue once before,
so maybe there's a bug under certain conditions.

-- 
Basil

Re: Our use of the "fixed" tag in debbugs

[Glenn Morris]

"Basil L. Contovounesios" wrote:

> Eli Zaretskii [2021-10-08 14:21 +0300] wrote:
>
>> Btw, "close NNN XX.YY" doesn't mark the bug as "done", see

Yes it does.

> But I feel like I've run into a "closed but not done" issue once before,
> so maybe there's a bug under certain conditions.

I don't know what "closed but not done" really means, but this sounds
like either:

"forgot to (b)cc the control server"  (so not closed at all)
or
"closed by forcemerge with an already closed bug" (so closed but no
   new "done" message gets sent out)

Re: Our use of the "fixed" tag in debbugs

[Basil L. Contovounesios]

Glenn Morris [2021-10-08 11:41 -0400] wrote:

> "Basil L. Contovounesios" wrote:
>
>> Eli Zaretskii [2021-10-08 14:21 +0300] wrote:
>>
>>> Btw, "close NNN XX.YY" doesn't mark the bug as "done", see
>
> Yes it does.
>
>> But I feel like I've run into a "closed but not done" issue once before,
>> so maybe there's a bug under certain conditions.
>
> I don't know what "closed but not done" really means, but this sounds
> like either:
>
> "forgot to (b)cc the control server"  (so not closed at all)
> or
> "closed by forcemerge with an already closed bug" (so closed but no
>    new "done" message gets sent out)

I looked earlier but couldn't find the one I was thinking of
unfortunately.  My impression is that I closed the bug somehow, received
an email acknowledging that I'd closed it, but on bugs.gnu.org it didn't
say "Done".  Perhaps you're right and I misunderstood at the time or am
misremembering.

-- 
Basil

Re: Our use of the "fixed" tag in debbugs

[Stefan Kangas]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> I looked earlier but couldn't find the one I was thinking of
> unfortunately.  My impression is that I closed the bug somehow, received
> an email acknowledging that I'd closed it, but on bugs.gnu.org it didn't
> say "Done".  Perhaps you're right and I misunderstood at the time or am
> misremembering.

I have managed to confuse myself in the past by looking at a bug report
to soon, before debbugs has had time to process it.

Other times, I have visited the page, but actually saw an old cached
version, and had to manually reload the page to see that the bug was
closed.  I don't know if this always happens, or if that was just an
exception, because I now habitually reload the page to make sure I am
always looking at the latest version.