Re: Checklist request (was: RFC: Deb 2.0 testing process)
> On Wed, 10 Dec 1997, Philip Hands wrote:
> > > For example, with the diff package:
> > >
> > > Package: diff
> > > - cmp works on identical and different binary or text files
> > > - diff works on files, directories, normal or 2 column
> > > - sdiff correctly merges two files
> > > - diff3 correctly compares 3 files
> > It seems a shame to have to ask people to do this sort of thing.
> > It strikes me that one should be able to come up with a script that does a
> > test of this sort in not much more that the time required to write the
> > list (in this simple case at least ;-)
> This is the second time I've heard this, and it is a valid point. The
> reason I don't fully back it is a tester using their own test may catch
> some case the package designer never thought of.
True. People should certainly not be discouraged from free-form testing.
This could also be a criticism of checklists to some extent, since they will
have a tendency to guide people into thinking about testing things in a common
> How about this, a
> maintainer can make a script, called /usr/doc/<pkg>/testme.sh. It can run
> any test the maintainer wants to do. In the checklist, the maintainer
> writes that the script is available, and test for the below things...
> This way, the testers can add their own things to the checklist even if
> the maintainer disagrees.
> Just because something works in the past doesn't mean it won't fail in the
> future. It would be nice if we can catch some bugs that haven't happened
True, but impossible of course ;-) How can anyone be expected to come up with
tests for bugs that have not happened ?
IMHO saying things like ``gut feeling'' or ``experience'' is just another way
of saying that it's happened before, maybe not to Debian, or maybe not as an
official bug, but it will have happened before (probably rather painfully to
the person with the experience ;-)
I just wanted to make sure that the checklists did not end up having items on
them that have never been known to fail, because testing such things is a
waste of testers time. The testers would soon get the idea that those tests
Admittedly, I cannot think of anything that has never gone wrong, off hand ;-)
but this approach struck me as a fairly easy basis to generate checklists.
Is there somewhere that one can see closed bugs that are older than 28 days ?
> The bash bugs come to mind (with netscape not running any helper apps).
But a test of some other aspect of Netscape that _has_ failed in the past
would most likely have spotted that, as a side effect. I seem to remember
netscape being totally unusable on my system, so it wouldn't have needed to be
an exhaustive test ;-)
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .