launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

This isn't deeply thought out, but I wonder if we can get rid of
'product', 'distro' and 'distrosourcepackage' bugtasks (and thus
conjoined masters). If this mail gets a reasonable level of interest,
I will LEP this up and socialise it more widely.

More concretely, when we built malone we had the idea of a 'bug in a
package', 'bug in a project' and 'bug somewhere in Ubuntu'.

We also wanted to be able to model bugs in prior releases, or in
different long term parallel releases and that turned into both series
tasks and per-version data [which we haven't got in the system today -
also known as infestations].

In the very early launchpad there was /no/ requirement for series.
ProductSeries was an optional extra.

Then it turned out we had a lot of special cases and we did some data
fixing + code changes and made ProductSeries and DistroSeries
mandatory - it was no longer possible to have a Product without a
trunk (or something like a trunk) and likewise distros.

So it seems to me, that in our current model, if we moved *all* the
product bugtasks onto their trunk series; and ditto Ubuntu tasks to be
natty tasks, and lastly Ubuntu sourcepackage bugtasks to be Ubuntu
natty sourcepackage bugtasks, we could remove the concept of 'Pillar
as a whole' bugtask.

Why would we do this, and what about when releases happen?

Making this simpler would make Launchpad easier to understand, easier
to develop on, and faster.

There are four main release models I've seen:
* Don't: run trunk or go home.
  - launchpad
* Trunk is always releasable, releases are snapshots of trunk.
  - bzr in the past
* Make a branch from trunk at-or-before-release, and the release is on
the branch, point releases carry on on the branch.
  - bzr now
  - Debian
  - Fedora
* There is no trunk, only specific release branches including one
whose name/number is that of the next intended release.
  - Ubuntu

So the question is how this would map into each of those four models.

* Don't:
  - maps easily: tasks are on a single series

* Snapshots of trunk
  - also maps easily: use milestone based releases to capture the bugs
included in a given release.

* Branch before release
  - Maps easily: make a new series when the branch is made and use
nominations to bring across bugs from trunk which also affect the
release series and need fixing before release. [Or backporting].

* Specific release branches only with trunk getting relabelled at each release
  - This maps a little less well because all the bugs which were -not-
fixed in a given release need to be promoted to the new focus when the
focus is changed.
  - It also would regress -slightly- in functionality because the
current practice of nominating *into trunk* to identify special-case
bugs would no longer work. However, using milestones for release
planning would still work, as would using the critical importance, or
tags.
  - It would also bring bug task management into line with how source
packages and branches are handled at releases of projects using this
model.

Finally, here is what we could gain:
 - drop the product and distribution columns from bugtask (2 ints * 900K rows)
 - simpler check constraints
 - simpler logic - bug targets would always be series objects not pillars.
 - clearer constraints on bug reports: we have multiple situations at
the moment where bugs are not clearly relevant/not relevant to a
series. E.g. the open bugs report for Ubuntu - should it include bugs
on natty (it doesn't). and bugs for natty (should it include open bugs
on Ubuntu? (it doesn't)).

-Rob