Supporting package to team mappings effectively

The information in package-team-mapping spreadsheet (team associated with package) should be incorporated into launchpad, rather than being a separate limited visibility spreadsheet.
Work Items:
[kate.stewart] - set up meeting (micahg, Daviey, skaet): DONE
[micahg] - confirm approach of using package sets will work with cjwatson: TODO
[kate.stewart] GAPS in subscriptions (subscribed but not looked at) - needs to include community: TODO
[bdmurray] - (and/or ursinha) create a report of the packages in main and their subscribers and untriaged bug task count. - I've updated skaet's spreadsheet with a list of packages in main and maintainers/subscribers -- Ursinha. DONE
[micahg] file bug number on subscribing to package sets. (Bug #884442): DONE
[ursinha] - (and/or micahg) talk to launchpad people if it's possible to use packagesets this way (lifeless or flacoste). - bigjools said packagesets are mainly to structure archive uploads permissions, so we'd need to adapt it to fit this other purpose. The alternative would be to change launchpad, but as the change needs to be done in Soyuz, and Launchpad team is down to one (maintenance) squad, this approach is not really viable now (unless I'm missing something). DONE
[ursinha] determine if it is possible to use packageset.searchTasks() (needs to be equivalent to ubuntu.searchTasks(bug_supervisor=my_awesome_team)) - It's not possible to do this. A packageset doesn't have a searchTasks method, so any search here would be as we do today: fetching the list of packages than looking for bugtasks on each of them: DONE

IF package set approach is ok:
[kate.stewart] work with each team to get package sets created/analyse reused as appropriate and communicate what we're doing.
[ursinha] have script to translate set of package sets to a package:subscribed teams list.
[defect-analysts] validate the set team matches expectations of various teams.
[bjf] translate reports to use new mechanism.

-----------

This information is necessary to drive the following processes:
- team bug analysis activities
- release management (overview of packages - hierarchy for summarization)
- identifying gaps in support coverage (packages without clear ownership)
- security support monitoring list

The following use cases need to be supported
- generate overview list of packages per team for release, available as csv
   - for release analysis and manual gap identification of support holes
- easy way for teams to change packages they're interested in.
   - team subscription to package defaults it that team?
   - what happens when multiple subscribes - need way of resolving, and still letting
     multiple teams get the notification the want.
- easy and efficient way for reports to access the primary contact team, for aggregation and
  summary purposes.

Other thoughts:
- probably this can be a single field associated with package, with a pre-approved list of values only.
  (ie. teams who will be tracking and responsible for it only - not all launchpad teams).
- its possible that mapping will change on a per release basis how can this be accounted for

UDS Session Notes:

Ideas:
- Moving the information from the spreadsheet into launchpad, what's the best way to handle it.
- http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html
this has an example of the bug tasks being split up amongst the teams who are responsible for the packages
use case
   - quickly and easily identify which teams are responsible for which packages
   - Identify who the first point of contact for a package is.

- Right now teams are subscribing to bugs about the package
  - problem is that there are multiple teams subscribed to a package so who is first?
  - additional problem that not all main packages have subscribers
  - kate - every seeded universe package should have a subscriber too
  - robert indicates that 'subscribed to' is only an interested in mechanism
  - robert suggests having a team that is composed of responsible teams (canonical-foundations etc) that would be used for reporting instead of using a static list of responsible teams
  - kate says there should be 1:1 mapping for statistics

- Use bug supervisor to search for bugs on packages that the team cares about.
  - Not right long term - for multiple reasons.
  - Brian Murray has script that takes a package set and subscribes them as bug subscriber. Package set list generated with API.
   - Subscribing team - which package team is responsible for.
   - Script searches all packages in archive and output the teams subscribed to the package.

Main idea: Use package sets
  - Today: Package sets and teams related to them are possible.
  - Problems:
    - Ubuntu server - GIMP isn't something they'll be using.
    - Python bindings example. Aspect view not registered. Binary hint.
  - Filing bug against source or one of the binary packages. Noise on it. Aggregation of information. Who does it make sense for it to speak to.
  - Package sets to teams was intention - but not being used effectively.
    - Would like - Package sets being used for limited test rebuilds. (example).
    - Person/team/set with upload rights. Can't have members, only contact address, or DMB/TB owns.
  - ok to have package belong to multiple package sets.
  - controlled who can do set this - TB
  - Whitelist of teams that can subscribe to a package set.
    - HOW
      - temporary interest
      - release based (package sets updated per release.)
      - Manual one: don't have upload rights - package set.
      - Package sets with no members in it.
        - Create with no people in it - not to worry about upload rights.

  - Server report: Package set and Team subscription is used to generate this.

  - Idea is: create a packageset for a team that includes the packages that team is interested in
     - Subscribe to a package set: Bug 884442
  - Problems:
     - Inconsistent usage of tasks. Targetted for release.
     - How publish it wider.
     - Setting tasks, core developers.
     (see irc from uds-bonaire4 - include in)
      - Tasks who to speaks to progress. "First contacts" - progress to triaged.
 - Sample list with packagesets (notice the multiple package set listings):
  - https://launchpad.net/ubuntu/precise/+localpackagediffs?field.name_filter=&field.package_type=non-ignored&field.package_type-empty-marker=1&field.packageset=100

 - Requirements:
  - easy way to change packageset membership
    - Currently only Archive Admin or owner of the package set can modify.
    - There is a tool in ubuntu archive - No upload rights - flag