Launchpad bug statuses

[Christian Robottom Reis]

On Thu, Oct 04, 2007 at 01:07:07AM +0900, Emmet Hikory wrote:
>     This status has also been being used to indicate that an
> Ubuntu-specific patch has been prepared by someone without commit
> access (which may continue to be the case whether the packages are in
> RCS or not).  I don't mean to imply that it should mean that there is
> a known fix somewhere, but rather that all work necessary to apply the
> fix, saving the upload, has been completed (but may benefit from final
> review / approval).  Please also consider the workflow for
> non-developer contributors and developers with limited upload access
> (MOTU) when planning possible status transition flows.

Indeed. One assumption in the status -- perhaps unwritten -- is that Fix
Committed implies that the fix has been /oficially approved/. In RCS
terms for upstream, this means that the patch has been merged to trunk;
it will be Fix Released when there is actually a downloadable tarball
that includes the fix (glossing over projects that never release, such as
ViewCVS).

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

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

> 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?

>     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).
-- 
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125