Simon McVittie <[email protected]> writes: > On Tue, 12 May 2026 at 10:25:30 +0200, Simon Josefsson wrote: >>Can't anyone subscribe to the packages they are interested? Just click >>'subscribe' button? What's the advantage of [email protected]? > > The advantage of [email protected] is that it's obvious that sending > mail to [email protected] (or something that eventually reaches that > address, like bugs.debian.org) is the intended way to email the > maintainers, because it's the *only* way to contact the maintainers.
That's not obvious to me - does anything in Debian Policy or developers-reference explain that alias? I don't monitor that e-mail alias for packages I help with, nor did I know that I should (or even know how). Btw, the search function on https://www.debian.org/doc/debian-policy/ is awful, how do I search for a simple string like "packages.debian.org" in debian-policy or developers-reference? I believe the recommended way to reach maintainers of a package is [email protected] with "Package: FOO" for that package. That's the contact method that I monitor for "my" packages. /Simon > (Secondarily, it's also (more) explicit that subscribing to the > package on the PTS is the intended way to subscribe to package > updates, because it's the only way to subscribe.) > >>> I am not interested in an avalanche of mails from which I am not >>> interested in 80 % of them. >> >>I agree -- thus [email protected] doesn't seem ideal. But >>some other magic e-mail address? It could even go to /dev/null. > > If there's a magic email address that is the maintainer of these > packages, then well-intentioned contributors will look up that address > in the Packages file (or equivalent) and then send email to it, and > then not get any response from the maintainer-of-record, defeating the > purpose of declaring a maintainer email address. > > On one hand, you could argue that those well-intentioned contributors > are simply wrong and should always have been using [email protected], > but on the other hand, there's a lot to be said for Rusty Russell's > "How Do I Make This Hard to Misuse?" (which was about kernel API > design, but the same principles can apply in many other places). If we > aim to make the obvious thing correct and/or make the wrong thing > impossible, then we can eliminate a whole category of mistakes. > > We sometimes already see this in teams like GNOME, Python, Games where > there is basically nobody (perhaps literally nobody) subscribed to the > avalanche-of-mails mailing list, because instead, all maintainers are > subscribed to either the few packages that they personally "own" or > have touched recently (particularly in "loose" teams like Games and > Python), or the "team" group on the package tracking system if they do > want the full fire-hose experience. > > smcv > >
signature.asc
Description: PGP signature
