Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS
On Mon, Jan 16, 2017 at 12:17:48PM +0100, Ole Streicher wrote:
> Santiago Vila <sanvila@unex.es> writes:
> > On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
> >
> >> IMO, we should trust the maintainer and their decisions until there is
> >> no experience that it doesn't work. Which means: keep the maintainer
> >> fully responsible on the package, including the ability to lower
> >> severity of a CI test or any other bug. Only if we experience that this
> >> doesn't work, we need other measures.
> >
> > Well, it does not work:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843038#10
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841098#78
>
> This comes out of different interpretations of whether builds that
> sometimes fail (but often not) are RC buggy. You know that also I have a
> different opinion here.
>
> So, if you really want to have your interpretation to be the commonly
> accepted one, you should discuss it here and see whether you reach a
> common acceptance with your interpretation.
I think it should be the other way around, because Release Policy
already says "Packages must autobuild from source" and it does
not say anything about failure thresholds.
In fact, I've seen maintainers downgrading FTBFS bugs that happen more
than 50% of the time.
With the lax interpretation, we could have policy reversed, as in
"packages must not build from source", and the package
would still be policy compliant!
Schrödinger paradox! Packages are simultaneosly compliant with Release
Policy and with the reverse of Relese Policy!
This is why I can't trust (all) maintainers to do the right thing
regarding random FTBFS failures.
So, if you people are considering to put a piuparts-like blocking to
testing migration, please consider what will happen when the failure
happens randomly.
BTW: Your idea of an automatic RC bug would be a good start indeed,
and it's probably the least we should do.
Thanks.
Reply to: