• debbugs
• BugSubscriptionIdeas

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