Launchpad bug retesting

[Emmet Hikory]

Jonathan Jesse wrote:
> Cody A.W. Somerville wrote:
> > They've already produced the bug if they've reported it. It is
> > obviously important to ask if it is reproducible every time but the
> > more critical information is determining _how_ to reproduce it. If you
> > can't reproduce it on the version they're using, then obviously you
> > can't assume it is fixed on the development release because you can't
> > reproduce it there. Although, I imagine it would be safe to close the
> > bug or ask for them to try and reproduce it if the version of Ubuntu
> > that the bug occurred on is no longer supported and you can't
> > reproduce the bug in a version that is supported. So, although you
> > test, I don't think a lot of people do.
> >
> > Goals are important here. I don't think the goal should be to close as
> > many bugs as possible. I believe the goal is to have as many bugs
> > triaged _correctly_ so that they can be dealt with effectively.
>
> I agree the goal is make sure the bugs are triaged correctly, not necessary
> limit the size of Launchpad... I was trying to figure out exactly what the
> OP would suggest doing instead of requesting the indviduals to test things
> out on Hardy or for further detail if an update solved the problem.
> The goal is not to have the highest launchpad karma, but to make Ubuntu
> better

    The trick is to be sure that a given bug is actually fixed
completely.  In most cases, it is more useful to have a description of
how to generate the bug which can be tested against various releases,
than to confirm that the bug reporter no longer experiences the bug.
Sometimes a bug depends on some irregularity (e.g. the wxwidgets bug
that only happened for people with non-ascii GECOS names), or on the
users's locale (e.g. encoding assumptions when working with zip
files), but these specifics may not be obvious to the reporter, and
may not be easily replicated from a test install or from the liveCD
(and many users are uncomfortable installing a development release to
verify the bug).

    Rather than asking if the bug can be reproduced in the current
version, it may be more helpful to record the steps taken to try to
reproduce the bug, and report that it could not be reproduced, asking
the reporter to provide any corrections to the procedure.  Ideally,
the bug tester should confirm both that they can reproduce in the
previous release, and cannot reproduce in the current release, but not
everyone runs parallel releases, so this may not be so simple.

-- 
Emmet HIKORY