Nominating a bug for a distro series affects all package tasks for that distro

[William Grant]

Symptoms
========

Doing a nomination affects all current tasks in the (distro/product). This is surprising and prevents selection of just one facet of a complex bug.
After a nomination is done, its impossible to nominate newly added tasks. This prevents adding series tasks for packages which were identified as affected after the original nomination was accepted.
Trying to workaround the latter restriction via email results in an OOPS: OOPS-816CEMAIL3.

Analysis
========

Nominations are tracked as (bug, *series) pairs, which is insufficient for distributions which have subcomponents. This means that when a bug with several package tasks is nominated for a release, all the packages are effectively nominated, and the unique constraint in the database table prevents a successive nomination when a new package is added to the bug. Further to that, if an existing task is moved outside of the bug context - for example to a different distribution or different product, the nomination becomes entirely bogus : but the datamodel cannot realise that.

Possible solutions
==================

* Make bug nomination link to a bugtask. This would get the thing being nominated from the task, and the series to nomination from from the nomination. Some form of synchronisation to keep nominations fresh (or perhaps just destroy them) when a task changes context (distro,product) will be needed.
* Add a component field to bugnomination - sourcepackagename. This too would require synchronisation in the event that a bug has the matching task removed/retargeted.

[Stephan Rügamer (sruegamer)]

I can reproduce this behaviour especially when I have to work with security bugs.
Nominating different releases for different versions of a source package in one bug report is not possible.
This is a bug and needs to be fixed.

[LaserJock (laserjock)]

Indeed, this really can make SRU/security tracking difficult. See for instance but #163845 . In this case we are tracking a security vulnerability in python (and all python versions are vulnerable). Only certain releases are relevant for a particular python package. Python 2.2 and 2.3 only needs a dapper task, python 2.4 needs all current releases and python 2.5 only needs gutsy, feisty, and edgy tasks. So, we ended up having to have tasks for all releases for all python versions.

[Graham Binns (gmb)]

I'm re-triaging this as Critical since it needs fixing before bug 162411 can be considered fixed (indeed, fixing this one may well fix that bug).

[Graham Binns (gmb)]

Moving this back to Triaged. A discussion with wgrant and lifeless yesterday highlighted that this bug may well go away in the near-mid future when some attention is paid to fixing the way that nominations work. Fixing this bug in isolation would be a wasted effort.

Fixing the OOPS, however, is a good idea, so I'm going to create a separate bug for that. Apologies for the status flap.

[Curtis Hovey (sinzui)]

@poitr
Stop changing the status of this bug. It is Triaged...we know what needs to be done and that we want to do it.