= Associating package sets and distro series =

In the [[/OriginalAnalysis|previous analysis]] of the problem two possibilites
to associate package sets and distro series were identified. The conceptually more attractive one ([[/OriginalAnalysis#cow|Copy on write]])
unfortunately comes at a considerable higher cost and risk.

Currently, there are three types of data that relate to package sets: the

  1. package set inclusion hierarchy (a [[http://en.wikipedia.org/wiki/Directed_acyclic_graph|DAG]] that captures how package sets hang together)
  1. many-to-many inclusion relationship between package sets and (source) packages (captured by the `packagesetsources` table)
  1. package set based archive permissions (stored in the `archivepermission` table)

There is a requirement to tether the latter two to a distro series for the purposes of distro development.

There is also a (somewhat vague) realisation that package sets are "interesting" data that could potentially be utilised more widely across Launchpad coupled with the concern that their utility would be diminished if they were to have a distro series "life span" i.e. if we introduced a new incarnation of a package set (with a new database key) whenever the development of a new distro series begins.

On the other hand, the only package set use cases we have are the ones put forward by the distro development team.

Is it worthwhile pursuing a compromise that

  * avoids
    * limiting the life cycle of package sets to a single distro series
    * the complexity/risk/cost of the [[/OriginalAnalysis#cow|copy on write]] approach
  * gives the distro development team a clean slate for every distro series when it comes to
    * package set and (source) package inclusion relationships
    * archive permissions

If we wanted it we could e.g. add a `DistroSeries` foreign key to the `packagesetsources` and the `archivepermission` tables ([[https://pastebin.canonical.com/23233/|PATCH]]) as well as engage in a bit of data cloning in the database for each new distro series (when a new distro series `(ds-N+1)` is created, all `packagesetsources`/`archivepermission` rows for `ds-N` are copied and immediately updated to refer to `(ds-N+1)`).

A shortcoming of this approach is that the package set hierarchy is "global" i.e. cannot be changed for each distro series anew.

BTW, here's another [[https://pastebin.canonical.com/23240/|schema modelling variant]], more along the lines of the [[/OriginalAnalysis#sno|"shared nothing"]] approach. The assumption is that the original package set and its ''clones'' (introduced in the process of initialising new distro series as time goes on) form a package set "group".

The forthcoming Launchpad work-flows would then rather be referring to a `packagesetgroup` as opposed to specific package sets (that are tied to their respective distro series).