Re: proving a bug is gone
Adam Di Carlo <apharris@burrito.onshore.com> wrote:
> 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).
We can always put test cases in a debian/tests/ directory, if that
is important to the upstream maintainers.
> The debian-testing group is actually working on this issue as well,
> someone should liase with them.
Agreed. But I'm at a loss here -- I don't see a debian-testing
mailing list, and I don't see any testing links off of the
developer's corner of the web site.
> 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?
Er.. you're saying that you're marking the bug as fixed when it's only
been forwarded upstream? That's a different state than closed, isn't it?
I agree though that if we had a policy of creating tests for packages
that we'd need the bug tracking system to have a "closed except for a
way to test it" state. And, I don't think that bugs in that state
should hold up a release.
--
Raul
Reply to: