So I think there are two issues here - one is that we make triage
something that requires effort rather than being the default: we don't
present the bug database in a way that facilities driving the new queue
to zero. Secondly, *because* triage requires specific consideration, in
any project with > 75 bugs, untriaged bugs quickly blow out of control.
If I understand the problem statement correctly, this can be described
accurately as:
"backport/SRU additional bugtasks require manual triage"
with the assertion that something that is worth backporting/doing an SRU
will usually have the same priority and importance as the original task.
This now makes a lot of sense to me and I'm going to update the
description accordingly, please tell me if I got it wrong :)
** Summary changed:
- Better defaults when creating new series task
+ backport/SRU additional bugtasks require manual triage
** Changed in: launchpad
Status: New => Triaged
** Changed in: launchpad
Importance: Undecided => High
** Description changed:
- 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).
+ 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.
- 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.
+ If such new tasks inherited the priority from the highest series task
+ the target already has, they would rarely need to be changed.
- This will help with the consistency of the bug database and get the
- priorities closer to being right by default.
+ 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.
** Description changed:
When opening an additional task for an existing target (e.g. a source
- pakcage) this is usually a backporting / SRU / long term support update
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/777824
Title:
backport/SRU additional bugtasks require manual triage
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs