Launchpad bug statuses

[Emmet Hikory]

On 10/4/07, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Thursday 04 October 2007 01:00, Emmet Hikory wrote:
>
> >    ... The parallel case of rejecting bugs
> > for which nothing is happening is already established as a manual
> > workflow (at least for Ubuntu), and so does not become worse through
> > automation (regardless of any perceived benefits or detriments to
> > users, reporters, triagers, contributors, developers, etc.).
>
> I pretty strongly disagree with this.
>
> Different teams and projects have different standards for how long is long
> enough.  In Ubuntu Backports we don't (until LP took away the choice) close
> bugs that have been incomplete as they are usually incomplete due to lack of
> sufficient testing.  This testing, depending on the package in question, may
> take quite some time.

    Thank you for the counterexample.  I'm in agreement that automated
adjustment of bug status can be dangerous, but was unaware of existing
processes that were broken by the automation of bug invalidation (as
opposed to the ongoing manual invalidation documented by the
bugsquad).  In any case, I believe this particular issue was well
discussed in a separate thread previously, and that further
adjustments are underway (if I interpret the launchpad-users archive
from late September correctly).

> My perception is that LP developers have a "right" way to use LP in mind and
> do not appear to be very open to alternate visions.  As an Ubuntu developer,
> LP is a tool to work on Ubuntu and so the end state of the distro at release
> and through updates is what matters, not the purity of the bug database.

    Personally, I believe it is in the interest of a strong final
product for developers to have a concept of the "right" way for things
to be done, and for new workflows to be added to the list of use cases
for the system as it matures, rather than being imposed externally.
With a strong set of use cases, and a shared understanding of terms,
it should be possible to both provide for a comfortable workflow for
development and maintain the purity of the bug database.  Having a
single extended workflow for all Ubuntu teams would likely make it
even easier for new people to help, and improve the end state of the
distro at release (assuming a smooth transition to a workflow with
comprehensive support).

-- 
Emmet HIKORY