Adam Di Carlo <[EMAIL PROTECTED]> 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
