On 27/05/2025 17:46, Julien Plissonneau Duquène wrote:
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
IMHO, this is a security flaw, not a feature. I hear that everyone loves
it, so at least the emails should be authenticated somehow (@debian only
maybe? one-time register-confirm emails?).
1. process new requests and give feedback instantly
My opinion now is that debbugs runs pretty frequently, but emails get
rejected randomly, leading to a 30min wait for mail queue reruns. This
is probably a mail server config issue.
2. hide e-mail addresses from public (unauthenticated) web browsing
Yes please, and email headers hidden from even authenticated users. No
one needs to know anyone's home/work IP address and what provider they
use. IP Address is covered under PII in GDPR/UKGDPR/etc.. and debian
doesn't even warn about it and it's stuck forever online.
With pseudo-headers, there is no need for SMTP headers anymore.
3. have a web UI that makes it possible to submit bugs, reply to bugs,
manipulate bugs
4. have some GitLab (Salsa) integration
5. have better, restructured, simplified documentation with full examples
Current documentation is good actually, but you have to find the right
page. And if #3 is easy enough to use, don't need to RTFM to send a
special email.
6. track merge requests.
May I also add:
- Proper email handling, can't just change From/To/Subject on a
DKIM-signed email and forward it along, email servers don't like it and
report it automatically as abuse at original sender.
This needs ARC which is complicated. Or just forward from debbugs email
only.
BTW I don't think that Bugzilla, GitLab issues or even JIRA would be
suitable replacements for debbugs. FWIW some Apache projects including
the whole Maven project are now migrating away from JIRA to GitHub
issues, but they also have a fairly different usage pattern than Debian.
For Debian maybe something like Redmine could work (I'm not suggesting a
change, but looking at alternatives may give some ideas).
None of these are a drop-in replacement or perfect, but they all have a
Database data model (faster search/query), some API endpoint
(REST/SOAP/...), account management/SSO, client-side processing (dynamic
dropdowns, expand/collapse javascript, basic web 2.0 ajax stuff), some
"product" or grouping mechanism for authorisation (not open to everyone
flat list of packages), and a form of workflow/status per issue "type"
that you can see (debbugs only has tags/flags).
Having said all that, any improvements would be highly appreciated.
Thanks for looking into it.
--
Regards,
Ahmad
