Re: proving a bug is gone
- To: debian-policy@lists.debian.org
- Subject: Re: proving a bug is gone
- From: Daniel Martin <dtm12@jhunix.hcf.jhu.edu>
- Date: Sun, 08 Nov 1998 16:36:19 -0500
- Message-id: <[🔎] 87softvpd8.fsf@cush.dyn.ml.org>
- In-reply-to: Adam Di Carlo's message of "Sun, 08 Nov 1998 16:17:37 -0500"
- References: <873e7x1k1i.fsf@tiamat.datasync.com> <74NzWXk1w-B@khms.westfalen.de> <873e7vzcf1.fsf@tiamat.datasync.com> <19981107204834.A18168@test.legislate.com> <87g1buyc44.fsf@tiamat.datasync.com> <19981108085023.A29304@test.legislate.com> <13893.42072.52083.946292@sonny.econ.queensu.ca> <19981108093001.U20906@test.legislate.com> <13893.45000.262027.553781@sonny.econ.queensu.ca> <19981108100627.W20906@test.legislate.com> <[🔎] oak915ope6.fsf_-_@burrito.fake>
Adam Di Carlo <apharris@burrito.onshore.com> writes:
> Raul has suggested to add test cases to debian/rules to certify that a
> bug is gone. As much as I think our documentation should encourage
> maintainers to write test cases, I believe this puts undue stress on
> package maintainers. Moreover, if we do not have the cooperation of
> the upstream maintainers, writing test cases is going to be very
> difficult (they are generally very sensitive to minor changes in the
> code).
>
> The debian-testing group is actually working on this issue as well,
> someone should liase with them.
>
> But again, my personal opinion is that it would be a *mistake* to
> require certification that a bug is closed before uploading a
> fix. Take my case; I maintain MH; it is totally un-maintained upstream
> and obsoletely by nmh. My maintenance principle is to take the path
> of least resistance when fixing bugs; sometimes, even, I just forward
> them to the (dormant) upstream maintainers and just suggest to the bug
> submitter that active development should be directed towards nmh, not
> MH. Now, why should policy suddenly tell me I'm wrong to do this?
I also am most worried by this prospect. I maintain fvwm95 - most of
the bugs, when manually reproduceable at all, involve odd X manuevers
that I can't even begin to think about writing automated tests for.
And then there are those bugs that mysteriously seem to disappear for
no reason at all.
Perhaps a "checklist" of manual tests for bugs combined with an
automated script to check for bugs that can be tested that way (Hmm -
perhaps a strongly suggested /usr/doc/<package>/bugfixlist ?) might
be an option, but really I'd just prefer to rely on maintainer
competence not to reintroduce bugs.
Reply to: