Launchpad bug statuses

[Emmet Hikory]

On 10/4/07, Scott Kitterman <ubuntu at kitterman.com> wrote:
> > I imagine a bug flow where a) the root cause is
> > understood ("Triaged"), b) a patch is prepared ("patch" tag or
> > attachment flagged as a patch), c) someone (without direct commit
> > access) does all the work and tests to make sure everything works, and
> > uploads the results to a private branch, alternate repository, debdiff
> > patch, etc.
> >
> >     I've previously seen bug status management for this procedure as:
> >
> > a)  Bug status set to "Triaged"
> > a->b transition) Bug status set to "In Progress" whilst the patch is
> > prepared b) "patch" tag added or attachement uploaded with patch flag,
> > status set to "Triaged"
> > b->c tranision) Bug status set to "In Progress" whilst the packaging is
> > done c) Bug status set to "Fix Committed" to indicate a complete solution
> > is available for application

> For MOTU workflow the key event for a non-developer wanting something uploaded
> is subscribing ubuntu-universe-sponsors to the bug.
>
> I think setting it back to Triaged/Confirmed or up to Fix Committed isn't a
> big deal.  I don't think that given the semantics associated with
> Triaged/Confirmed, they are appriate when there is a fix ready for review.

    For MOTU workflow, I'd agree.  For standard Launchpad Behaviour,
I'm less certain:  I really like the workflow I've seen for a couple
upstream projects that involves 1) identification of a bug, 2)
determination of the root case & generation of simple test case, 3)
Preparation of a patch to resolve the issue, 4) reviews / comments /
votes by community members regarding the patch (frequently including
alternate patches until there is consensus), 5) patch application (to
trunk or to stable release update branch), 6) release (usually once
several patches have been applied).  Also in this case, a mechanism
for contributors to indicate that they have done the necessary
integration / unit testing work to transition from a quick patch
solution to testable production code ready for application is a good
means to interest fresh community members and allow demonstration of
abilities prior to the grant of commit access.

    More applicably, for packages that are RCS managed, should a
request to apply a patch to the RCS (or pull a merge from another
repo) by someone without commit access be subscribed to one of the
sponsorship groups?  Unless that sponsor group has access to the RCS,
this may result in a synchronisation loss between the RCS and the
available package or result in the patch not being applied because the
right people don't see it.  Subscribing the package management group
doesn't necessarily help either, as they are likely already subscribed
to all bugs for the relevant package, and so the resulting default
display lists will not provide the information that there is a patch
to be applied (or merge to be performed).  Note that the mere presense
of the X-RCS tags may not be sufficient to avoid collissions due to
the possiblility of confusion between Debian RCS maintained packages
and Ubuntu RCS maintained packages.

> In general I feel like we have a good bugfix workflow in MOTU.  I'd hate to
> see it disturbed because we've been using LP "wrong".

    While I agree that the current bugfix workflow does a fairly good
job of communicating status to reporters, contributors, developers,
and sponsors, I'm less certain that there is not scope for
improvement, especially through formalisation of standard meanings for
LP bug status strings.  On the other hand, such a migration only works
smoothly if the various use cases for bug management are well
understood, there is a transition plan for all affected workflows, and
there is some consensus that such a migration provides future benefit
among the stakeholders (which really should include users as well as
application developers, distribution maintainers, and launchpad
developers).

    In at least some cases, more automated updates may generate a
false sense of progress to reporters, who may become confused when
nothing happens (generating mail to developer lists, IRC discussion,
new bugs, forum traffic, etc.).  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.).

-- 
Emmet HIKORY