Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
Santiago Vila <sanvila@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: