Santiago Vila <sanv...@unex.es> writes: > No, really it's not. It's already current practice:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org > https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org > https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org > Are you suggesting that we should refrain from reporting FTBFS bugs as > serious unless we have a build log from buildd.debian.org in our hands? No, I'm suggesting that you should continue to report FTBFS as serious, but if the maintainer downgrades the bug to important because it's not reproducible on the buildds and seems to be an artifact of the test rebuild environment and they don't have time to fix it immediately, you should at least consider whether that's possibly a legitimate response depending on the specific situation. And that one should at least take a look at such bugs, ideally, before letting them auto-remove packages from testing (although I understand that no one really has much time to do that). I cannot over-stress how demoralizing it is to have your packages removed from the archive right before a release because you didn't have time to fix a bug like this due to life reasons. I am all in favor of continually ratcheting up the quality expectations that we have for Debian packages, but please be sensitive to whether the specific bug you've discovered is *really* release-critical, in the sense that the package is going to cause some problem or not be maintainable in a stable release. For many, many FTBFS bugs, the answer is yes, it's release-critical. But I don't think that's true for every instance of someone attempting to build a Debian source package and having it fail. > I'm sure you are not, but I've seen people downgrade bugs "because they > do not happen in buildd.debian.org" and at the same time nobody of them > realize what would happen if we followed such silly (and wrong) rule in > a consistent way. I have sometimes downgraded such bugs because, as it turns out, the person who reported the FTBFS bug was building in an unclean environment (stray bad configuration files, stray partly-removed conflicting packages, etc.). I want my packages to build everywhere, and I don't think there's been a case of this where I've not managed to fix it, but I don't consider ensuring that the package builds in absolutely any environment to be release-critical. > Well, maybe what it's excessively aggressive or questionable is to run > the tests at build time and making the package build as a whole to fail > when any test fails. *blink*. I'm quite surprised that you would advocate not failing a build if tests fail during the package build? I think that would be an awful way to proceed. My packages have test suites for a reason. I do not want packages to appear to successfully build if their tests are failing. That may mean that the resulting binaries are nonfunctional or even dangerous. > I have the feeling that this autopkgtest things should be used (among > other things) to de-couple package builds from package testing. autopkgtest is useful for adding additional tests of the built binaries, but I don't believe it's intended as a replacement for build-time testing. Maybe I've missed something? > No, the appropriate reaction would be to disable the failing tests via > NMU until the maintainer exits the hospital and can investigate. That would certainly be fine, and I'm signed up for every "please NMU my packages" list I can find, but we both know that time to do this for all packages is pretty short in the run-up to the release. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
