Re: Renovating debbugs (was Re: Interesting learnings about Guix contributor dynamics that apply to Debian?)
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.
Yes, i think that is the most realistic way.
I've been thinking for some time how to improve debbugs.
Partially in light of toying with the idea to make a full featured TUI
client for it(which i might never find the time for, but).
>
>
> 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
This will be essential. Also keeping the existing path as is and adding new
ways to interact allows experimenting with new sementics without breaking
current usage.
> 1. process new requests and give feedback instantly
I think greylisting is a big factor here.
E-mail just isn't what is used to be any longer.
For non email frontends i think one important feature to consider is a way to
submit change requests to debbugs without email.
Feeding a e-mail like text directly to debbugs in an authetificated way (say
using a token obtainable from a salsa account) would allow for much faster
feedback.
> 2. hide e-mail addresses from public (unauthenticated) web browsing
This seems problematic in the current state of debbugs as this likely breaks
a lot of use cases. Or forces everyone to be logged in, in some way.
The mailto: links are very valuable to work with existing bugs.
At least as debbugs doesn't work like mostly every other bugtracker by auto
subscribing participants.
Consider moving that part to later in the timelime.
>
> 3. have a web UI that makes it possible to submit bugs, reply to bugs,
> manipulate bugs
This of course is the big new thing.
One part where i could see this loosing is reportbug integration, so maybe
one thing to consider would be to allow this to be triggered from reportbug
as well (i.e. have reportbug send the user on to the webinterface with a
prefilled bugreport template instead of trying to submit via email as
option).
I wonder what semantics would be good for web based interactions.
The way debbugs currently works seems not like a good fit with what users
expect from web based bug tracker interactions.
Or the email systems don't really like emails with From coming from
webservers that don't submit through the email providers submission path
anymore.
Thus i wonder if the web interface wouldn't be a good chance to add a part to
debbugs that aligns more with what works well today and matches now expected
email privacy.
I assume the web interface will need authentification for changes/bug
submission. Say using salsa (otherwiese replace salsa by something else
below).
Currently debbugs uses email adresses as identities. Maybe it should gain
salsa accounts as a new identity type (possibly by encoding them as special
email adresses). Then all interactions triggered by salsa identities could be
send from a fixed infrastructure address (somewhere in debian.org or
debian.net?) with just the "display name" set to the salsa identity
information.
Those would not be reachable directly by email, but instead would just be
subscribed to the bug and receive updates from debbugs as subscribers and not
by direct mail from users replying via the tradition email interface.
(This loose the easy way to take discussions private, there could be an
opt-in to still allow taking discussions private)
For the web based changes i think it would be worth to explore if the UI
could be based around use cases more than raw manipulation of fields.
i.e. have a flow for "the maintainer forgot to include a 'closes: '" instead
of just having a "fixed in version" field.
In a way the current state of things makes it more unlikely that fields are
set in a wrong way, because it hardish to learn how to set them in the
first place. When getting rid of that kind of barrier it might be good to
consider getting solid UI flows that explain when some action is apropriate
to keep mistakes low.
Also as debbugs has some more complicated interactions it would be nice to
get a preview what the new state of a bug would be.
For alternate (external) frontends it would be nice to have that preview
available as some kind of api.
>
> 4. have some GitLab (Salsa) integration
>
> 5. have better, restructured, simplified documentation with full examples
yes, please. I always struggle with the current documentation.
>
> 6. track merge requests.
>
> 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.
I think the way debian works it is currently not feasable to protect all
email adresses in all usages.
An interesting thing to think about is what happend if a bug ends up on a
mailing list (e.g. Maintainer is a mailing list or a mailing list is CCed in
later).
Having non email identities on debbugs would still allow these interactions
to work as long as the bug is also included in the replies to the mailling
list (which usually is the expected way).
I think emails in git and in mailling list is quite a differnt topic.
>
> 6. is not clear enough. What would we like debbugs to achieve, more
> precisely, here?
This sounds like a big topic.
One thing i really think the web based git repos do a lot better than the
email based workflows is giving context to patches.
Ideally (where enabled) patches in bug reports would be just another view to a
merge requests on salsa. But of course that sounds very very hard.
>
>
> BTW I don't think that Bugzilla, GitLab issues or even JIRA would be
> suitable replacements for debbugs.
I would expect nothing widely used has enough flexibility to do such basic
tasks as tracking migration of fixes. Also switching would need parallel
system or a flag day both which sound like nearly impossible.
- Martin Hostettler
Reply to: