Christian Robottom Reis wrote:
> On Wed, Oct 03, 2007 at 06:31:08AM +0900, Emmet Hikory wrote:
> > > It might, but then you get into the problem of distinguishing whether
> > > there is a patch out there in the wide world or in your official RCS
> > > repository (or a package in a random repository versus -proposed).
> >
> > The location and origin of the fix shouldn't matter, as long as
> > the correct solution is clearly available from the bug (attached or
> > linked), and represents a debdiff against the current package, a
>
> Fix Committed is intended to tie in with an RCS commit at some point
> down the line, so keep that in mind when considering what it is useful
> for. We can already do it for upstreams, but for distribution packages
> it is more difficult as there isn't really a standard way to
> revision-control packages yet (it's a hard problem to solve).
>
> I guess for now you're right -- if we are noting that a fix is somewhere
> available, Fix Available would be more correct -- but I'd rather not
> rename the status unless we've given up on RCS for packages (which we
> haven't!)
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.
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
indicates the first, "In Process" seems inappropriate, especially as
such bugs may no longer be assigned to anyone (as the previous
assignee cannot upload the package), and the next available status is
"Fix Committed".
> Well, we could display something special in the row if at least one
> other bugtask is fix committed or fix released. That could help solve
> that part of the problem. I'm trying to find out if there's a bug
> reported for this, but I'll make sure there is if not.
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
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.).
Also, in some cases, such a notation doesn't always capture the
same information as a human-reviewed status adjustment. For example,
if a bug has been fixed in the development version and latest release,
but is outstanding for a LTS release, there may have been sufficient
changes to the underlying libraries, etc. that the fix cannot be
trivially uploaded (which seems to be the sense of "Fix Committed").
This may be of especial interest when considering security-related or
global infrastructure compatibility (see Tor thread) bugs.
--
Emmet HIKORY
This is the launchpad-users mailing list archive — see also the general help for Launchpad.net mailing lists.
(Formatted by MHonArc.)