Manoj Srivastava <[EMAIL PROTECTED]> writes: > Hi > >>"Raul" == Raul Miller <[EMAIL PROTECTED]> 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.
