Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Mon, Jan 16, 2017 at 12:02:32PM -0800, Russ Allbery wrote:
> Santiago Vila <sanvila@unex.es> writes:
>
> > Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> > even if they did not happen in buildd.debian.org yet?
>
> This seems excessively aggressive.
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?
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've had FTBFS bugs in my packages
> that were due to specific configurations for archive mass rebuilds that
> were not reproducible on buildds, and while those are certainly bugs that
> I wanted to fix, I think making them RC is questionable.
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.
I have the feeling that this autopkgtest things should be used (among
other things) to de-couple package builds from package testing.
Then people who test that packages build ok would have one thing less
to worry about.
> [...]
>
> Remember, making a bug RC says that we're going to remove the package from
> the archive if the bug isn't fixed. Suppose either of those had been
> reported near the release freeze and I was, say, in the hospital or
> something and simply couldn't look at them. Would the appropriate
> reaction to either of the above bugs be to remove the software from the
> release?
No, the appropriate reaction would be to disable the failing tests via
NMU until the maintainer exits the hospital and can investigate.
Thanks.
Reply to: