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: * n...@bugs.debian.org — such messages are also sent to the package maintainer and forwarded to debian-bugs-dist, but not to the submitter; * nnn-submit...@bugs.debian.org — these are also sent to the submitter and forwarded to debian-bugs-dist, but not to the package maintainer; * nnn-mainto...@bugs.debian.org — these are only sent to the package maintainer, not to the submitter or debian-bugs-dist; * nnn-qu...@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) [cjwat...@debian.org]
