The 'bts done' command uses the 'close' control command to close bug
reports. This command has been deprecated for almost 20 years (since at
least February 2002) [0,1] and goes against the best practices set out
in §5.8.2 of the developer's reference:

    You should never close bugs via the bug server close command sent to
    control@bugs.debian.org. If you do so, the original submitter will
    not receive any information about why the bug was closed. [2]

Please use NNN-done@bugs.debian.org instead.

Similarly, the undocumented command 'bts close' should be dropped.

[0] https://web.archive.org/web/20020202152705/http://www.debian.org:80/Bugs/server-control
[1] https://www.debian.org/Bugs/server-control#close
[2] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#responding-to-bugs
--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

Control: tag -1 moreinfo

I really disagree.

There are uses of closing a bug without notifying anybody, and I really
want `bts` to retain that use.

If you are going to do something notifying people, you already really
ought to write a longer mail, at that point you may as well send the
mail to nnnn-done@ yourself, IMHO.

funnily enough, I don't think I ever used `bts done` but I used
`bts close` many times  :D  I never even realized it was undocumented…

(fwiw, I also normally mail nnnn-close@ instead of nnnn-done@, "done"
is just too hard on my mind since I really want to close a bug, not
"mark it as done", whatever that means.)

I suggest a new design for bug closing:

Make `bts done` and `bts close` both be able to do notified closings
and silent closings.

Add command-line options --notify and --silent to `bts done/close`,
make --notify the default for `bts done` and --silent for `bts close`.

Add config file options for each of `bts close/done` to let people
customise them independently as desired.

Change the template for notified closings to mail -done instead of
control@ and place a Version pseudo-header into the template even when
a version isn't specified.

[snip]

Where should this version come from?  I think the feature you're
describing works like:

  1. Install Debian.
  2. Triage bugs, and find a bug.
  3. Confirm that this bug does not exist in the version of the package
  that is installed.
  4. Run this "bts" which basically means "close the bug, it's fixed on
  my installation".

The main pitfall that I can think of is the case where the bug is fixed
in an older package version, but present in the newer.

I'm guessing you don't mean getting a fake version from rmadison.
Alternatively, isn't there somewhat of a convention for tag
+unreproducible bug-done@d.o?  In this case, it also doesn't seem like
you'd want a Version pseudo-header.

Cheers,
Nicholas

...

Its hard to remember what I was intending, but probably make the bts
notified closing template include an empty pseudo-header, which the bts
user would then either remove or fill in before sending the mail.

Le Sun, Aug 17, 2025 at 09:26:16PM +0200, Bill Allombert a écrit :

Thanks, I did not think about that option.

Keeping in mind that this is one of many bugs I either updated or closed
through the bts command-line tool. Maybe that tool should be improved to
use xxxxx-done@bugs.debian.org instead of control@bugs.d.o and
xxxxx-submitter@bugs.d.o?

Checking bug reports against devscripts, I found one that is about this
topic: https://bugs.debian.org/996968. I added this bug report as Cc so
this e-mail can serve as a reminder that bts is still triggering a
behaviour that go directly against what is documented in Debian
Developer's Reference.