Re: proving a bug is gone
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: