Activity log for bug #110195

Date Who What changed Old value New value Message
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 Adig 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