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).
> > 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.
> > 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.).
> > 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.").
--
Emmet HIKORY
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)