[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lack of replies



On Thu, Jan 04, 2024 at 04:52:58PM +0100, Daniel Gröber wrote:
> That's certainly not something I'd advocate for. I want us to minimize the
> PITA for the technically literate without sacrifising general usability.

To be honest, I think that address rewriting might actually be part of
improving usability of the BTS - but it would have to be done carefully
and with an eye to various other features that have evolved as
workarounds for the current situation.  It may be that some other
changes need to happen first.

The original design had a collection of addresses for each bug, all of
which were filed in the system itself, and some of which are also sent
on to others.  As seen on https://www.debian.org/Bugs/Developer:

 * nnn@bugs.debian.org — such messages are also sent to the package
   maintainer and forwarded to debian-bugs-dist, but not to the
   submitter;
 * nnn-submitter@bugs.debian.org — these are also sent to the submitter
   and forwarded to debian-bugs-dist, but not to the package maintainer;
 * nnn-maintonly@bugs.debian.org — these are only sent to the package
   maintainer, not to the submitter or debian-bugs-dist;
 * nnn-quiet@bugs.debian.org — these are only filed in the bug tracking
   system (as are all the above), not sent to anyone else.

This has been a mostly functional but slightly problematic design for as
long as I've been involved with Debian.  The classic problem is that
people email a followup to a bug to nnn@bugs and (without much thinking
about it) expect it to be seen by everyone who's interested in that bug.
But in fact this doesn't automatically go to the submitter, nor
necessarily to anyone else who's been involved in the discussion on the
bug.

In practice, if you're receiving the bug discussion by email, then you
can reply-all and it'll usually be more or less OK - but if the email
thread is at all non-linear then people may well end up being left out
by accident, people can easily forget to reply-all rather than just
reply, and it's not exactly obvious how to participate in this way if
you weren't already CCed.  ("bts --mbox show nnn" exists and is OK for
experts, but it's not exactly obvious and probably only works with some
MUAs.)

At some point debbugs gained a "subscribe" feature: you can email
nnn-subscribe@bugs to subscribe to a bug, or nnn-unsubscribe@bugs to
unsubscribe, with a confirmation message in each case.  So far so good,
though clunky.  But submitters aren't auto-subscribed, and you can't
really tell who's subscribed so you have no way to know in advance if
your message is going to reach the right people.  (The implementation is
also kind of weird: IIRC it's done via lists.debian.org, so even the BTS
itself doesn't really know who's going to get the message.)  As a
result, while this helped with certain use cases, it didn't really solve
the problem above.

What I always thought would be a better model would be for each bug to
be a "nosy list" (the term comes from roundup, I think).  That is, bugs
would have a list of addresses notified of changes, by default filing a
bug or sending a message to it would cause you to be added to the list,
and subscribing to or unsubscribing from any given bug would be easy.

Now, such a change would certainly require some people to adjust a bit,
and it would be easier if the BTS had an optional authenticated web
interface to allow you to (un)subscribe more easily.  I'm not saying it
would be straightforward.  But if things worked this way, then I think
rewriting addresses to nnn@bugs would ultimately be less controversial -
it would be the most convenient default, as the address that's most
likely to reach everyone you probably want it to reach.

-- 
Colin Watson (he/him)                              [cjwatson@debian.org]


Reply to: