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
