Re: keeping a fixed bug fixed (was Re: proving a bug is gone)
Manoj Srivastava <srivasta@datasync.com> writes:
> Hi
> >>"Raul" == Raul Miller <rdm@test.legislate.com> writes:
<SNIP>
> Raul> I'm not talking about a complete regression test suite here.
> Raul> I'm talking about simple test cases. If the code dumps core
> Raul> under some condition, reproduce the condition and see if it
> Raul> still dumps core. If it's not easy to write a test, put it on
> Raul> a checklist and punt the issue for later.
>
> Not all bugs produce a checklistable item.
<SNIP>
> Raul> The only exception I can see is where the bug can't be reproduced at
> Raul> all. And I'm wondering if we ought to have a special way of closing
> Raul> those kinds of bug reports [to enable later analysis].
>
> Let us see how relevant this is Here are my list of resolved
> bugs. Let us see..
>
> 29 bug reports.
> 2 cases whre reproducers were possible, one whereit is available
> 6 possible test, with 3 being noted as tricky
> 23 cases where one could put thinkgs on a checklist, 9 cases where it
> just clutters things up. Therefore only 14 out of 29 cases that even
> a checklist makes sense.
<SNIP>
<List o' bugs deleted>
I will repeat my suggestion (since when I first made it, it was in a
parenthetical comment and I wasn't quite certain what I meant by it
anyway) for a "List of fixed bugs" to be included either under
/usr/doc/<package>/ or at the very least in the debian/ subdirectory
of the source package.
There could be a somewhat standardized format, as there is with the
changelog, describing in a few sentences (?) the bug, how to reproduce
said bug (if known), and why/when it was fixed and/or closed. (That
is, for fixed bugs a package version number of the fix could be given)
Also, the relevant BTS numbers could be given in a bug's entry,
perhaps leading to some automatic bug-closing system. (Which I like a
slight bit better than the "closes=" attribute in the changelog, since
that bit of the changelog format might tend to encourage "closes
#xxxxx" changelog entries, with no details on what those bugs were to
begin with)
This allows for some of the same functionality as a checklist, but
with the proper tools (an interface to the BTS for pulling down bug
descriptions perhaps?) I doubt it would cause much more administrative
work. Until said tools are written, however, I propose we merely
decide on a name and format for this list-o-fixed-bugs and say that if
a file in the debian/ hierarchy with this name exists, then it must
contain fixed bug information in the agreed upon format. I wouldn't
even go so far as to encourage maintainers to keep such a list until
there exist tools to make it easy to do.
Reply to: