On Launchpad Bug Status values

[Emmet Hikory]

    A month ago, an official list of Bug status values was published
on launchpad [1].  Without a discussion of the appropriate
classification of the various statuses that are used to track bugs
that may someday be fixed, I would like to hear if other MOTUs would
find an additional rejection status would be useful, defined as
follows:

"Deferred"

    This status indicates that while this bug is valid, and there is
sufficient information to understand the cause, there is no current
intention to fix the problem by the project against which the bug is
reported.  Deferred is meant to capture the cases where a reporter's
request is unlikely to be addressed in the project, and the reporter
would do well to pursue other channels in parallel.

"Deferred" is distinct from "Invalid" in that an "Invalid" bug
represents a case where a bug doesn't represent something that can be
fixed, whereas "Deferred" bugs could be fixed, but nobody is going to
do it.

"Deferred" is distinct from "Won't Fix" in that "Won't Fix" represents
a case where either the perceived problem or recommended solution is
contrary to the plans of the project, or the scope of the issue is
beyond the ability of the project to complet, whereas "Deferred" bugs
represent soluable issues.

"Deferred" would typically only be useful to projects that distrbute a
collection of software, including contributions from many other
sources (such as a distribution (e.g. Ubuntu)), but would be used to
specifically notify reporters that while such a problem exists, it
will likely be solved more quickly upstream, while still indicating to
interested parties investigating the bug database that code to provide
such a solution would not be unwelcome.

"Deferred" should be hidden from the default buglists (as "Won't
Fix"), and there should be two automated status adjustments
associated, as follows:

    1) If there is a registered upstream task, and the upstream task
acquires a status mapped to "Won't Fix", the "Deferred" task should be
transitioned to "Won't Fix", as it is not appropriate to fix at a
distribution level when upstream has already rejected it.

    2) If there is another registered task (upstream or not), and that
task acquires a status mapped to "Fix Committed" or "Fix Released",
the "Deferred" task should be transitioned to "Triaged" to indicate
there is an available solution, and someone should investigate
integration.

The primary goals in adding "Deferred" in addition to "Won't Fix" are
1) to encourage parites browsing the buglist who are interested and
capable to contribute code, but also indicates that it is neither a
priority nor likely to be committed without review by the project; and
2) to ensure that when fixes to these issues become available (either
upstream or in another distribution), they are again raised for
attention in Ubuntu.  Without this status, many bugs are marked "Won't
Fix", as Ubuntu doesn't have the resources or attention, and yet are
later fixed, which doesn't seem to be the best feedback to submitters.

I'd like to hear others opinions as to the utility of this proposed
status.  If there is consensus, I intend on coordinating with the MOTU
launchpad liaison to request inclusion in a future release.

1: http://news.launchpad.net/general/of-bugs-and-statuses

-- 
Emmet HIKORY