There are a couple of scenarios in which I would find it useful to
be able to reserve a bug number somehow, and then create the real bug
report later:

* If there's an embargoed security vulnerability in a package that I
  work on, I would like to be able to ask the BTS to reserve a bug number
  for me, and mention that bug in patches/the changelog/etc., so that on
  unembargo I can create a bug in the appropriate package/versions/etc.
  with details of the vulnerability.

* Or if I'm reporting a simple bug for which I intend to supply a patch
  immediately, I would like to be able to reference the bug as
  "Closes: xxx" in the patch, so that the package's maintainer or a
  NMUer can immediately apply it if they approve, with no further changes
  or bookkeeping required - this would be particularly useful for
  undermaintained packages where I want to minimize the work that the
  presumably overworked maintainer needs to do.

A possible workflow for this:

* send a command to the BTS to reserve a bug number or a small block of
  bug numbers (perhaps up to 10 at a time, or something)
  - this could be done by email or through a web interface
  - perhaps this could require a PGP signature by a DD/DM/known contributor,
    or a Salsa OAuth transaction, or some similar mechanism to avoid
    trolls reserving millions of bug numbers; or perhaps it would just
    require a reply to a magic address (like subscribing) for traceability
  - for the embargo use-case, it would be best if this did not require
    me to specify a package: the reservation could be associated with my
    username or login name or key, but not a specific package

* the reply to that command tells me the bug number(s), and perhaps some
  sort of unique single-use token to use when "committing" each one

* I make a note of the bug number(s), and the token(s) if any

* I go away and fix the security vulnerability or write the patch,
  and I can use the reserved bug number (let's say 123456) in my
  changes

* when I'm ready, I submit a new bug report to the BTS as usual, with a
  header or pseudo-header that says "use reserved bug number 123456"
  - perhaps Reserved-Bug-Number: 123456 1d5fd64d-7f0d-43b4-bdba-f53e66c6df67
    where 1d5fd64d-7f0d-43b4-bdba-f53e66c6df67 is the token I was given
    when I reserved it
  - or perhaps using this mechanism would require a PGP signature or a
    Salsa OAuth transaction or an email reply or something
  - trying to use a bug number that was not reserved in this way, or was
    already used, would be an error; the BTS should either reject the
    submission, or ignore the requested bug number and create a new bug
    with a new unique bug number instead

A crude implementation of this would be to reserve a bug number by sending
an essentially empty bug report to an unmonitored pseudo-package, and
then when I'm ready to submit the actual bug report, reassign that bug to
the target package with all the details, cc'ing its @packages.debian.org
address; but that seems unnecessarily noisy.

    smcv

On Fri, 30 May 2025, Simon McVittie wrote:n

These are some interesting use cases! Thanks for sharing them.

[...]

This is what I'd suggest right now, and is probably along the lines of what
I'd implement, since anyone can mail any bug at any time or modify any bug at
any time. The key issues right now are:

1. It's not possible to update the initial submitted message with a new
   message to the BTS.
2. There are significant differences between the information you get as
   maintainer on reassignment of a bug versus what you get when you
   submit a new bug.

Once 1 and 2 are fixed, the workflow would be:

submit bug with fake package (you'll get a warning that the package doesn't
exist, but that's OK) to reserve a bug.

send new message with details, patch, etc. and use the control pseudoheader or
equivalent to reassign the bug to the correct package, set the right
version, retitle, etc.