| 2007-04-26 07:26:45 |
William Grant |
bug |
|
|
added bug |
| 2007-04-26 07:28:17 |
William Grant |
description |
I just tried to nominate (can I take this opportunity to again point out that motu should probably have the rights to accept/decline them?) the k3d source package task of bug #64848 for Feisty. It seems that Malone decided that I'd asked for it on the olive task too. That shouldn't happen, as in many cases the bug won't be relevant to that release in the other source package. Added extra tasks to a bug when they weren't requested isn't a good thing. |
I just tried to nominate (can I take this opportunity to again point out that motu should probably have the rights to accept/decline them?) the k3d source package task of bug #64848 for Feisty. It seems that Malone decided that I'd asked for it on the olive task too. That shouldn't happen, as in many cases the bug won't be relevant to that release in the other source package. Adding extra tasks to a bug when they weren't requested isn't a good thing. |
|
| 2007-11-24 22:19:28 |
Stephan Rügamer |
malone: status |
New |
Confirmed |
|
| 2007-11-25 23:23:15 |
Matthew Paul Thomas |
malone: importance |
Undecided |
High |
|
| 2011-05-27 11:14:07 |
Graham Binns |
launchpad: importance |
High |
Critical |
|
| 2011-05-27 11:37:13 |
Graham Binns |
summary |
Nomination for a release on one source package shouldn't affect any others |
Nominating a bug for a distro release affects all package tasks for that distro |
|
| 2011-05-27 11:41:27 |
Graham Binns |
description |
I just tried to nominate (can I take this opportunity to again point out that motu should probably have the rights to accept/decline them?) the k3d source package task of bug #64848 for Feisty. It seems that Malone decided that I'd asked for it on the olive task too. That shouldn't happen, as in many cases the bug won't be relevant to that release in the other source package. Adding extra tasks to a bug when they weren't requested isn't a good thing. |
Nominations-for-release are tracked at the Bug level, not the BugTask level (they're called BugNominations after all). This means that when a bug with several package tasks is nominated for a particular release, a BugTask is created for each package for that release. This is rather too coarse-grained; it should be possible to nominate each package for a separate release if necessary.
We should alter BugNomination to be BugTaskNomination and move the appropriate methods from IBug to IBugTask.
Fixing this will also fix Bug 162411. |
|
| 2011-05-28 20:41:20 |
Robert Collins |
tags |
lp-bugs motu |
lp-bugs motu oops |
|
| 2011-05-28 20:51:46 |
Robert Collins |
description |
Nominations-for-release are tracked at the Bug level, not the BugTask level (they're called BugNominations after all). This means that when a bug with several package tasks is nominated for a particular release, a BugTask is created for each package for that release. This is rather too coarse-grained; it should be possible to nominate each package for a separate release if necessary.
We should alter BugNomination to be BugTaskNomination and move the appropriate methods from IBug to IBugTask.
Fixing this will also fix Bug 162411. |
Symptoms
========
Doing a nomination affects all current tasks in the (distro/product). This is surprising and prevents sepection 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. |
|
| 2011-05-28 20:52:06 |
Robert Collins |
description |
Symptoms
========
Doing a nomination affects all current tasks in the (distro/product). This is surprising and prevents sepection 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. |
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. |
|
| 2011-07-06 13:24:48 |
Graham Binns |
launchpad: assignee |
|
Graham Binns (gmb) |
|
| 2011-07-06 13:26:29 |
Graham Binns |
launchpad: assignee |
Graham Binns (gmb) |
|
|
| 2011-07-06 13:31:05 |
Graham Binns |
launchpad: assignee |
|
Graham Binns (gmb) |
|
| 2011-07-06 13:31:50 |
Graham Binns |
launchpad: assignee |
Graham Binns (gmb) |
|
|
| 2011-08-15 09:02:17 |
Graham Binns |
launchpad: assignee |
|
Graham Binns (gmb) |
|
| 2011-08-15 09:02:20 |
Graham Binns |
launchpad: status |
Triaged |
In Progress |
|
| 2011-08-16 09:48:49 |
Graham Binns |
launchpad: status |
In Progress |
Triaged |
|
| 2011-08-16 09:48:49 |
Graham Binns |
launchpad: assignee |
Graham Binns (gmb) |
|
|
| 2012-06-15 12:13:07 |
Matthew Revell |
tags |
lp-bugs motu oops |
bug-relationships lp-bugs motu oops |
|
| 2012-09-17 13:04:50 |
Curtis Hovey |
tags |
bug-relationships lp-bugs motu oops |
bug-nomination bug-relationships lp-bugs motu oops |
|
| 2012-10-05 00:07:02 |
Curtis Hovey |
summary |
Nominating a bug for a distro release affects all package tasks for that distro |
Nominating a bug for a distro series affects all package tasks for that distro |
|
| 2013-06-14 12:58:04 |
piotr zimoch |
launchpad: status |
Triaged |
New |
|
| 2013-06-14 12:58:08 |
piotr zimoch |
launchpad: status |
New |
Incomplete |
|
| 2013-06-14 12:58:12 |
piotr zimoch |
launchpad: status |
Incomplete |
Opinion |
|
| 2013-06-14 12:58:16 |
piotr zimoch |
launchpad: status |
Opinion |
Invalid |
|
| 2013-06-14 12:58:20 |
piotr zimoch |
launchpad: status |
Invalid |
Confirmed |
|
| 2013-06-14 12:58:23 |
piotr zimoch |
launchpad: status |
Confirmed |
In Progress |
|
| 2013-06-14 12:58:27 |
piotr zimoch |
launchpad: status |
In Progress |
Fix Committed |
|
| 2013-06-14 12:58:37 |
piotr zimoch |
launchpad: status |
Fix Committed |
Fix Released |
|
| 2013-06-14 13:14:10 |
William Grant |
launchpad: status |
Fix Released |
Triaged |
|
| 2013-06-14 14:40:33 |
piotr zimoch |
launchpad: status |
Triaged |
New |
|
| 2013-06-14 14:40:37 |
piotr zimoch |
launchpad: status |
New |
Incomplete |
|
| 2013-06-14 14:40:42 |
piotr zimoch |
launchpad: status |
Incomplete |
Opinion |
|
| 2013-06-14 14:40:47 |
piotr zimoch |
launchpad: status |
Opinion |
Invalid |
|
| 2013-06-14 14:40:51 |
piotr zimoch |
launchpad: status |
Invalid |
Confirmed |
|
| 2013-06-14 14:40:55 |
piotr zimoch |
launchpad: status |
Confirmed |
In Progress |
|
| 2013-06-14 14:41:01 |
piotr zimoch |
launchpad: status |
In Progress |
Fix Committed |
|
| 2013-06-14 14:41:04 |
piotr zimoch |
launchpad: status |
Fix Committed |
Fix Released |
|
| 2013-06-14 14:58:47 |
Curtis Hovey |
launchpad: status |
Fix Released |
Triaged |
|
| 2016-05-16 05:29:55 |
Lukasz |
launchpad: status |
Triaged |
Fix Released |
|
| 2016-05-16 09:24:24 |
Colin Watson |
launchpad: status |
Fix Released |
Triaged |
|
| 2016-07-25 02:31:08 |
Thanatas |
information type |
Public |
Public Security |
|
| 2016-07-25 02:31:22 |
Thanatas |
bug |
|
|
added subscriber Thanatas |
| 2016-07-25 09:08:35 |
Colin Watson |
information type |
Public Security |
Public |
|
| 2019-02-24 22:10:35 |
Airkm |
information type |
Public |
Private |
|
| 2019-02-24 22:10:44 |
Airkm |
removed subscriber Airkm |
|
|
|
| 2019-02-24 22:13:31 |
Airkm |
removed subscriber Thanatas |
|
|
|
| 2019-02-24 22:13:31 |
Airkm |
removed subscriber Emmet Hikory |
|
|
|
| 2019-02-25 00:28:07 |
Brian Murray |
information type |
Private |
Public |
|
| 2019-03-28 22:24:27 |
faaaaa |
launchpad: assignee |
|
faaaaa (faaaaa) |
|
| 2019-03-29 14:58:28 |
Brian Murray |
launchpad: assignee |
faaaaa (faaaaa) |
|
|
| 2019-10-02 18:17:59 |
martin |
launchpad: assignee |
|
martin (mukamuka) |
|
| 2019-10-02 18:18:08 |
martin |
launchpad: assignee |
martin (mukamuka) |
|
|
| 2019-10-02 18:18:30 |
martin |
launchpad: status |
Triaged |
Fix Released |
|
| 2019-10-02 18:19:02 |
martin |
bug |
|
|
added subscriber martin |
| 2019-10-02 19:05:52 |
Colin Watson |
launchpad: status |
Fix Released |
Triaged |
|
| 2019-10-02 19:24:10 |
Alen Nedic |
bug |
|
|
added subscriber Alen Nedic |
| 2020-03-02 16:16:55 |
Colin Watson |
launchpad: importance |
Critical |
High |
|
