Make all bugtasks be for a productseries/distributionseries/sourcepackage

We currently require all products to have at least one series - the default one we create is called 'trunk'. If we do the same for distributions we could simplify our bug model which will make it easier to explain and optimise. The simplification would be to make all bugs be targeted to a series (of a product or distribution or sourcepackage (just Product from here on in for brevity)) rather than to either a series of a product or a product.

Contact: RobertCollins
On Launchpad: https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=onlyseriestasks See also: This mailing list thread details the change and has some good discussion.

As a User
I want Launchpads bug model to be as simple as possible
so that I have less to learn but can still get what I need done done

This LEP aims to slim down what we have without sacrificing features or capabilities.

There are four main release models projects seem to use:

• Don't: run trunk or go home; also projects with no releasable artifacts.
  • 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

How this would impact each of those 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.

Rationale

We are considering doing this now because:

• We have many rough spots in the user interface due to the split between 'series tasks' and 'product tasks. (For instance, the actual count of bug tasks for which work is required to do a release requires summing the bugs on the series + bugs on the product - but we don't do this and we regularly have folk be surprised when they realise that).
• Users get confused by forms only count bugs in a series (which series reports do) when they are examining point releases.
• We have some major upcoming work on bug visibility and a simpler model will reduce the code changes needed during that work.

Stakeholders

Changing our bug model in the manner proposed will have minor impact on the common case UI, but potentially dramatic impacts on the release management process. We should therefore talk with release managers and qa folk of major projects using Launchpad before committing to this design change.

• Ubuntu: Kate Stewart, Brian Murray, Jeremy Foshee
• Our top ten upstream projects by bug count:

 count |       name
-------+-------------------
 24333 | launchpad
 12205 | inkscape
  5833 | bzr
  4220 | openobject-addons
  4138 | ubuntuone-servers
  3645 | ubuntuone-client
  3641 | landscape
  3619 | moovida
  2916 | unity
  2670 | hundredpapercuts

Constraints and Requirements

Must

• Permit existing release management processes to work (perhaps with minor tweaks)
• Simplify Launchpad and make it easier to use and improve

Nice to have

• Performance improvements as a result of smaller table width.

Must not

• Prevent users getting work done

Out of scope

• Per-version tracking of bug occurences (infestations).

Subfeatures

Success

How will we know when we are done?

How will we measure how well we have done?

Thoughts?