= Use Cases =
Here's how things link up.
* 123456@bugs.d.o should become a mailing list
* Which initially has the submitter and maintainer subscribed to it
* People should be able to unsubscribe
* But unsubscribing should not mean not getting a note when the bug is closed
Here's who are "interested":
* The package maintainer team
* should not be able to unsubscribe?
* The submitter, and other folks who would've submitted the bug had it not already been filed
* should be able to unsubscribe
* but should still get -done notifications even if unsubscribed
* Upstream maintainers and other people involved in fixing the bug
* being able to search for bugs you've been Cc'ed on is useful
* useful to be able to subscribe
* Other people who need to know when the bug is fixed
* useful to be able to subscribe
* may relate to dependencies
So here are the sorts of people:
* Maintainers
* Always get everything
* Subscribers
* Get everything too
* Can unsubscribe
* "Important" subscribers
* Get notified when the bug is closed
* ...or tagged fixed or whatever
* "Interested" people
* Special BTS search option to select these bugs
In which case
* Maintainers and uploaders are "maintainers"
* Submitters are initially subscribers, important subbers and interested
* Cc'ed people should be marked "interested" in some sense
* Subscribers should be "interested" as well
* People should be able to record their interested bugs to an email address via the web/control too
Moving on, that means
* Interested
* Is a general sort of thing that should be flexible
* There should be different classes of interested
* set by cookies
* set by control / website and stored
* determined by looking at Cc's (?)
* set by an external program (ie, dump of email addresses)
* Subscribers
* Can be handled externally
* But subscriber lists need to be pushed back to debbugs for interested handling
* Need to be able to choose to subscribe to an "important messages" list
* Submitters
* Don't get cc'ed
* But do get automatically subscribed to the bug list
* And thus get two copies of done messages
= Integration with lists =
What about having a separate domain?
Would you rather send mail to "12345-subscribe@bugs.debian.org" ? Of course you would, everything else sucks. Hrm. So in that case, maybe the list stuff should be done on spohr, rather than elsewhere. Then it's a matter of piping, rather than setting up many addresses.
That means then having eoc (or whatever mlm is used) feed straight from incoming, and be invoked by processall, essentially.
= Implementation =
Conclusions.
* That means that the mailing list handling should be exim to receive to spamscan to processall to the mlm. And the mlm and subscription addresses/regexp should be configuration options.
* The mlm should export subscriber lists back to debbugs in some reasonable form. (Email addresses only)
* Interested handling should be made a little more general -- ie, you should be able to say "queries by 'subscriber' are determined by looking at this file for the bugs that 'subscriber' is interested in"
*
= Problems =
There's an issue with autosubscriptions in that you then potentially get duplicates. For example, if you file a bug against one of your own packages
= Old Implementation Notes =
One possible way of doing it, is just sending out bug mails to a single address that can then have a mailing list manager forward them on to interested people. That means:
* Send a copy of each mail to -bugs-dist
* Have headers indicating Bug#, Package, Source package, Maintainer, Submitter, Severity, blahblah
* Have a script that forwards those to people who've subscribed to
* the PTS
* a particular bug#
* a particular (source) package
* RC bugs
* ...etc