Launchpad bug statuses

[Scott Kitterman]

On Wednesday 03 October 2007 20:58, Emmet Hikory wrote:
> Christian Robottom Reis wrote:
> > On Thu, Oct 04, 2007 at 01:07:07AM +0900, Emmet Hikory wrote:
> > >     Perhaps what I'm looking for is an easy way to indicate 1) the
> > > root cause is well understood, 2) a patch is available, 3) the
> > > necessary packaging work to apply the patch is complete, 4) the
> > > package resulting from this work has been tested and does not have the
> > > bug, and 5) nobody is currently working on the bug.  "Triaged" only
> >
> > I would say:
> >
> >     1) Triaged
> >
> >     2) There's no special status for this right now. It could be a tag,
> >        or for bugs with an upstream task, a fix committed or released
> >        upstream task, or you could imply that a bug with attachments of
> >        the type "patch" are also part of this.
> >
> >        We could provide a unified report that attempted to list bugs in
> >        this state.
> >
> >     3) Fix Committed
> >
> >     4) This is something that happens after Fix Released; you could use
> >        a tag to indicate it. Bugzilla has a VERIFIED status that I never
> >        liked very much, but it does cover this case. The problem with it
> >        being a status is that I doubt even half of bugs actually go
> >        through formal verification, so you get some bugs stuck in Fix
> >        Released and others in Verified.
> >
> >     5) This is an unassigned bug in the Confirmed or Triaged status.
>
>     My apologies.  I rather meant a status that meant all of the above
> inclusively.  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
>
>     From what I'm understanding from your listing above, you would
> also like to use "Fix Committed" for the completion of all packaging
> work, but indicate this imples that all necessary review / approval is
> complete.  Given the possible delays between work completion and
> review / approval (some bugs are not reviewed within a full
> development cycle, even without any need to update a patch),
> continuing to use "In Progress" for this state falsely implies that
> someone is actively doing something (I'd also prefer not to break the
> concept that if a bug is "In Progress", one really shouldn't do
> anything without checking with the assignee: this invites competition
> and duplicate work).

Following this to it's logical conclusion, I'd say then that everything in 
Gutsy should be Fix Committed because it's not released to the distro user 
base yet (I don't think this is a good idea, but that's the logical 
conclusion).

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.

> > >     This would certainly be a benefit when checking the status of
> > > other bugs on a package before preparing an upload, but only helps if
> > > the fix is recorded or has been applied somewhere else.  I'm also
> >
> > Right. This is why I'd like to see recording the bug elsewhere happen
> > more often; I acknowledge it is right now too much work (though less
> > than it used to be).
>
>     For bugs related to packaging, integration, interpackage
> coordination, ABI mismatches, etc. there is often no other meaningful
> external location to file a bug.  These represent a large majority of
> the "foo doesn't work", "bar can't do quux", and "baz generates
> confusing error messages" bugs.  This is further compunded by native
> packages, for which all bugs are necessarily distribution specific.

In any case, until the barrier to linking upstream bugs is lower, I think the 
amount of linkage isn't going to significantly change.

> > > concerned about the case of Ubuntu-specific fixes that are available,
> > > but not yet published to the archive.  This is perhaps especially
> > > complicated if the fix has been committed to an alternate repository
> > > for testing / review prior to upload (e.g. SRUs, fixes with possible
> > > integration or architecture implications, fixes made available during
> > > freeze periods, backport candidates, etc.).
> >
> > Right. This is the "Fix-available-but-not-committed" variant situation.
> > I don't know how to handle this nicely without some manual labor such as
> > a tag, but maybe we will find a way. Maybe we need a task on an
> > alternative repository, which we could then mark Fix Committed?
>
>     As a developer, I'd like to be able to see such a status at first
> glance when looking at the bug list for a package: specifically it
> implies that there is no good reason for me not to include the fix in
> the upload I am preparing (probably for something else), and
> encourages more comprehensive maintenance (rather than lots of
> fixed-one-bug uploads), and reduces archive churn (saving disk space,
> server and client processing, bandwidth, coordination, etc.).

Agreed.

> > >     Also, in some cases, such a notation doesn't always capture the
> > > same information as a human-reviewed status adjustment.
> >
> > Indeed. I think that there will always be a set of bugs which will need
> > manual paying attention to; the trick is to reduce the workload of
> > identifying the /other/ bugs, which can be dealt with more easily (via a
> > sync, trivial packaging or rebuild).
>
>     I'd argue that automatically setting a flag depedent on a solution
> elsewhere does exactly the opposite: the likelihood of false positives
> means that each case needs review (and a busy developer may prefer to
> just upload the known working fixes).  I'd suggest that a "Fix
> Available" state (for which "Fix Committed" has been being used in the
> absence of widespread RCS packaging) should only be set by humans, to
> specifically indicate that a sync, rebuild, or trivial packaging
> (either review/upload or minimal integration with existing candidate)
> is required - this should indicate a lower level of review imposed on
> the developer ("is it sane?, does it address the issue?", rather than
> "what's this?,  Is it the same version?, how hard is it to extract
> from the other source?, etc.").  The specific humans moving the bugs
> from "some solution available somewhere" to "a specific, targeted, and
> complete solution exists for the current development target" need not
> have access to the repository, nor any official involvement in the
> project, but can be anyone with the necessary skills, interest, and
> time.  This vastly expands the available pool of talent to complete
> work, and acts as a useful proving ground for prospective developers
> ("Hi.  I want to be a developer.  I've fixed all these bugs" is more
> convincing than "Hi.  I want to be a developer.  I've been working
> with so-and-so to help them with their work.").

Yes.

I think automatic status setting based on external changes (or age) is a 
fundamentally bad idea.

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".

Scott K