| 2011-05-05 13:08:37 |
Kate Stewart |
bug |
|
|
added bug |
| 2011-05-05 13:09:06 |
Kate Stewart |
removed subscriber Kate Stewart |
|
|
|
| 2011-05-05 13:09:09 |
Kate Stewart |
bug |
|
|
added subscriber Kate Stewart |
| 2011-05-05 13:10:19 |
Kate Stewart |
tags |
|
ubuntu-platform ubuntu-qa |
|
| 2011-05-06 05:09:31 |
Robert Collins |
launchpad: status |
New |
Incomplete |
|
| 2011-05-07 10:06:36 |
Kate Stewart |
launchpad: status |
Incomplete |
New |
|
| 2011-05-08 09:14:21 |
Kate Stewart |
bug task added |
|
ubuntu |
|
| 2011-05-08 09:14:39 |
Kate Stewart |
ubuntu: importance |
Undecided |
High |
|
| 2011-05-08 09:34:29 |
Kate Stewart |
bug |
|
|
added subscriber Michael Hope |
| 2011-05-09 00:43:24 |
Robert Collins |
summary |
Better defaults when creating new series task |
backport/SRU additional bugtasks require manual triage |
|
| 2011-05-09 00:43:28 |
Robert Collins |
launchpad: status |
New |
Triaged |
|
| 2011-05-09 00:43:31 |
Robert Collins |
launchpad: importance |
Undecided |
High |
|
| 2011-05-09 00:48:17 |
Robert Collins |
description |
Bugs for a specific package, may need to be applied to multiple Ubuntu development series explicitly (SRU's, etc.). This is a also a common task when transitioning from one development release to another. (ie. natty to oneiric).
for a bug #
if a new series task opened,
inherit priority and status from
if development exists; inherit priority and status from development
if existing series; inherit priority and status from existing series.
This will help with the consistency of the bug database and get the priorities closer to being right by default. |
When opening an additional task for an existing target (e.g. a source pakcage) this is usually a backporting / SRU / long term support update situation. Bugs that are worth doing that for tend to be high or critical priority and doing manual triage is usually a bit boring and time consuming.
If such new tasks inherited the priority from the highest series task the target already has, they would rarely need to be changed.
The status of the new task could possibly be inherited, or perhaps start out as triaged reflecting that the new task has an importance and is for a known validated bug. |
|
| 2011-05-09 00:49:28 |
Robert Collins |
description |
When opening an additional task for an existing target (e.g. a source pakcage) this is usually a backporting / SRU / long term support update situation. Bugs that are worth doing that for tend to be high or critical priority and doing manual triage is usually a bit boring and time consuming.
If such new tasks inherited the priority from the highest series task the target already has, they would rarely need to be changed.
The status of the new task could possibly be inherited, or perhaps start out as triaged reflecting that the new task has an importance and is for a known validated bug. |
When opening an additional task for an existing target (e.g. a source package) this is usually a backporting / SRU / long term support update situation. Bugs that are worth doing that for tend to be high or critical priority and doing manual triage is usually a bit boring and time consuming.
If such new tasks inherited the priority from the highest series task the target already has, they would rarely need to be changed.
The status of the new task could possibly be inherited, or perhaps start out as triaged reflecting that the new task has an importance and is for a known validated bug. |
|
| 2011-06-20 09:35:20 |
Jonathan Lange |
tags |
ubuntu-platform ubuntu-qa |
bug-lifecycle ubuntu-platform ubuntu-qa |
|
| 2011-10-17 01:04:21 |
Launchpad Janitor |
ubuntu: status |
New |
Confirmed |
|
