On Tue, May 27, 2025 at 06:46:29PM +0200, Julien Plissonneau Duquène wrote:
Unlike some people I believe that debbugs can be improved and
modernized in a satisfying way while retaining most if not all of its
current interfaces. This would minimize breakage and inconvenience for
developers that are mostly fine with the way it currently works.
I endorse basically all of this. (I had really hoped to be able to put
significant effort into modernizing debbugs over the past year or so,
but it turns out that other projects are using up most of my
web-application-development effort, and the rest has been mostly going
into whichever of OpenSSH and the Python team needs more attention this
month ...)
I'm considering getting my hands into that thing later this year, so
let me try to summarize the relevant parts of the previous threads
(with the intent of documenting this in a wiki page).
We would like debbugs to:
0. keep all the e-mail features it currently offers
1. process new requests and give feedback instantly
2. hide e-mail addresses from public (unauthenticated) web browsing
3. have a web UI that makes it possible to submit bugs, reply to bugs,
manipulate bugs
In my view, an absolute prerequisite for all of this is moving from the
current flat-file structure to a proper database; the current data
structures just don't perform well enough to be usable as the foundation
for a modern web UI. Don has some branches on
https://salsa.debian.org/debbugs-team/debbugs that make a start at
switching to PostgreSQL, and he can probably fill you in on more
details.
4. have some GitLab (Salsa) integration
At least for signon, so that we don't have to track another set of
accounts. (And of course people would be able to keep using
unauthenticated email-based workflows anyway, per your point 0.)
5. have better, restructured, simplified documentation with full
examples
6. track merge requests.
I'm not very sure about point 6, but I think points 1-5 will be more
than enough to be getting on with and will likely make it clearer what
should be done next. Best to start with things that are reasonably well
understood.
Implementing 2. is likely to break habits and maybe some tools, as
currently there is no authentication at all on debbugs web UI and you
can use it to view full headers, download mboxes and generate a
working reply mailto: link. It also won't completely solve the privacy
issue, as e-mail addresses can also be found in git repositories and
mailing list archives. IMO it would be better to recommend using a
dedicated e-mail address.
Mostly agreed, though I do think the last sentence is a bit of a
cop-out. Yes, if you absolutely want to hide an email address then it
probably has to be a single-purpose one, but that isn't exactly an
excuse for debbugs being quite as liberal with them as it is.
I'd add that it's probably time to start sending out debbugs email
"From: Some Person <nnn...@bugs.debian.org>" rather than acting as a
sort of relay that modifies messages on the way through. The latter
approach made sense 20 years ago, but it's just not good enough at
ensuring deliverability in the modern internet. We made a similar
change a few years ago when I was working on Launchpad
(https://blog.launchpad.net/notifications/bug-emails-now-use-the-bugs-address-in-the-from-header)
and never regretted it.
It would have to be done thoughtfully (e.g. there might still need to be
some way to explicitly take a bug conversation private), but on the
whole I think that change would probably actually work better with the
more email-centric workflow of debbugs, where at the moment it's far too
easy for people to end up taking bug conversations private _by mistake_.
I'm bringing it up here because it's an important part of making sure
that debbugs doesn't just replay everyone's email addresses through to
mailing list archives.
--
Colin Watson (he/him) [cjwat...@debian.org]
