launchpad-dev team mailing list archive

[Muharem Hrnjadovic <muharem@xxxxxxxxxx>]

Meeting time: Wed 14-Oct-2009, 12:00 UTC
Meeting duration: 1 hour
Attendees: jml, BjornT, intellectronica, bigjools, al-maisan

Agenda:
  - Launchpad internal use cases and needs wrt package sets
  - Ways to put package sets into a distro series context while
    supporting the above

Package sets and their associated data (the package set graph they form
as well as what source package names and archive permissions they are
associated with) need to be put in a distro series context. This is a
hard requirement put forward by the distro team.
Basically, whenever a new distro series S2 is created it will get its
own copy of the package set data from the previous series S1. Changes to
S2's package set data are not to affect S1's data in any way.

Providing a fresh body of package set data for each distro series allows
the distro team to make whatever adjustments they deem necessary. These
can include changes to

  - package sets (e.g. to their names)
  - the package set graph (e.g. by removing/adding package subsets)
  - source package inclusion and archive permission relations

In order to support Launchpad use cases (like users subscribing to bugs
relating to packages in a certain package set) a more continuous view on
package sets (i.e. one transcending distro series boundaries) is needed
however. This is the rationale for introducing the `packagesetgroup`
table [3] that links package sets across distro series and name changes.

Use cases discussed:

  U1 - User subscribes to bugs pertaining to packages in a given
       package set by navigating to the latter's UI page and clicking
       "subscribe".  The reference stored internally is not to the
       package set at hand but to the `packagesetgroup` it belongs to
       however.
       When navigating to the respective bug view page the user expects
       to see bugs for the package set in the most recent distro series.
  U2 - User is subscribed to bugs pertaining to packages in a given
       package set and wants to see a "historical view" i.e. bugs for
       all package sets in the corresponding `packagesetgroup`.
  U3 - A user is an active back-porter and subscribes to bugs pertaining
       to packages in a package set PS and a *particular* distro series
       S0 i.e. when navigating to the respective bug view page the
       user expects to see bugs for PS in S0 as opposed to the bugs for
       PS in the most recent distro series.

Questions discussed:

  - How difficult are the queries for U1 i.e. how do I get my hands on
    a package set in the most recent distro series?
    The package set name and the series under development is all that's
    needed (only one distro series in the Launchpad database is marked
    as being under development at any one time).
  - Is there a need or use case for changing a given package set
    globally i.e. irrespective of distro series association?
    Very unlikely since
      - package sets will tend to diverge with each new distro series
        (different source packages, archive permissions etc.)
      - distro developers tend to focus on the distro series under
        development and change stable/supported series as little as
        possible.
  - How could we model the subscriptions for the use cases U[1-3] in the
    database?
    One possibility: a link table X (capturing subscriptions) with three
    foreign keys and a boolean flag:

            CREATE TABLE X (
                owner integer NOT NULL,
                packagesetgroup integer NOT NULL,
                distroseries integer,
                all_series boolean DEFAULT false NOT NULL
            );

    Please note how the distroseries foreign key is NULLable.
    The variants are as follows:
      - U1 type subscription: owner and packagesetgroup are set;
        the distroseries and the all_series flag are left alone.
      - U2 type subscription: insert a row with the appropriate owner
        and packagesetgroup into X; leave the distroseries column NULL
        and set the 'all_series' flag to True.
      - U3 type subscription: insert a row with the corresponding
        owner, packagesetgroup and distroseries into X; leave the
        all_series flag as is.

  - Should there be one global name for all package sets belonging to a
    particular `packagesetgroup` or should each package set have its own
    independent name?
    My understanding is that each package set needs to have its own and
    independent name. Package set names will be highly visible and
    appear e.g. in the /etc/apt/sources.list file.
    Also, when the distro team needs to rename a package set the new
    name is valid and known only from that point in time onward and
    *not* retroactively since that is likely to wreak havoc on
    stable/supported distro series.

Action points:

    - al-maisan: rename packagesetgroup to distributionpackageset
    - al-maisan: rename packageset to distroseriespackageset
    - al-maisan: touch base with the Ubuntu platform team, ask about
      their need to rename package sets.

Reading material:

  [1] A description of the issue at hand:
https://dev.launchpad.net/Soyuz/Specs/PackagesetsAndDistroseries
  [2] Package set user stories (Ubuntu platform team perspective):
https://dev.launchpad.net/VersionThreeDotO/Soyuz/StoryCards#packagesetacl
  [3] Database schema patch outline: http://pastebin.ubuntu.com/293189/

Attachment: signature.asc
Description: OpenPGP digital signature