Setup per-project error contacts

[Guilherme Salgado]

That way we make sure we send notifications to the appropriate people for any errors found when collecting data from LP. The below is a plan we discussed via email:

>> Those warnings are also sent to the registrant of the Blueprint (or maybe
>> the team leads), no? If that's the case, I think we should skip them here
>> as they're not really something *we* need to deal with.
>
> I think that particular error is not sent to someone else (no
> error_contact_pattern). Those error contact patterns are regexps
> defined in the linaro-config files. I guess there once was an agreed
> naming convention for linaro blueprints judging from those but that
> has gone astray.

Oh, I assumed it would send the error to the BP
registrant/assignee/whatever, but after having looked at the code I now
understand what's going on. So, the config has error patterns like this

   error_contact = {
     'linaro.*graphics': ['<email address hidden>'],
     'linaro.*toolchain': ['<email address hidden>'],

And then when there's an error on a given BP we try to match that BP's
name to one of the patterns and if there's a match we send the email to
the appropriate address. Now I see why the BP naming convention is
important. Maybe the only thing we need to do here is to update the
error_contact list the first time we see a warning like those?

Maybe instead of associating email addresses with regexes for BP names
we could associated them with projects. Then we could search for the
project name on the BP URL and if it's there we send an email to the
addresses associated with that project. We already maintain a list of
projects in the config, so it'd be just a matter of extending it to
include the email addresses that should be notified when there's an
error. Something like

   toolchain_notification_addresses = ['foo@l.o']
   extra_projects = {
     'gcc-linaro': ('4.6', toolchain_notification_addresses),
     ...}

Or maybe as a separate dict, so that we don't have to change any
existing code that expects the values in extra_projects to be a string.
Actually, to avoid repeating ourselves, we could turn all this into
something like

   class ToolchainProjects:
     notification_addresses = [...]
     projects = {'gcc_linaro': '4.6', ...}

   project_notification_addresses = {}
   extra_projects = {}
   for klass in ToolchainProjects, KernelProjects, ...:
     extra_projects.update(klass.projects)
     project_notification_addresses.update(dict.fromkeys(
       klass.projects, klass.notification_addresses))

Another benefit of having per-project contact addresses is that we would
also be able to use them to notify the appropriate people when the error
is not on a BP, e.g.:

   https://launchpad.net/qemu-linaro/+milestone/2011.11
     [ERROR] Milestone 2011.11 (qemu-linaro) has due_date 2011-11-10 but
     linaro-octo-armhf already has the due date as 2011-11-17 (no
     error_contact pattern)

Does that sound reasonable? I think it'd be very straightforward to
implement.

[Milo Casagrande (milo)]

Due to the age of this issue, we are acknowledging that it will likely not be fixed, is no longer applicable, or was already fixed by an indirect change. If this issue is still important, please add details and reopen it.