Re: Maintainer: Debian Commons

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.

(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