= 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

debbugs/BugSubscriptionIdeas (last edited 2005-07-14 15:13:17 by AnthonyTowns)