Santiago Vila <sanv...@unex.es> writes: > The following packages FTBFS for me randomly. First column is the bug > number, second column is the estimated probability of failure in my > build environment, which is described here:
> https://people.debian.org/~sanvila/my-building-environment.txt > Before I ask the Release Managers that they make the bugs at the top > of this list serious again (using some kind of threshold, as discussed > in Bug #844264), I would appreciate if somebody else could double check > that those packages have indeed very flaky tests (or buggy Makefiles, > in some cases). > [ Please report any findings to the nnn...@bugs.debian.org address ]. > While I agree that none of those individual bugs is more important > than a bug of "FTBFS-always" type, some packages have a failure ratio > so high that if we accepted that they "build from source" with such a > high failure rate, they would effectively honor policy if we had it > reversed, as in "packages must *not* build from source". I call this > "the FTBFS-randomly Schrödinger paradox". To say my opinion explicitly, since there's been a lot of discussion here, some of which I've been involved in somewhat ambiguously: I think this is a reasonably short and workable list of bugs, and I think the *default* assumption should be that any FTBFS, even intermittant, is RC. This is both for fundamental reasons for what we're trying to achieve as a free software distribution that's modifyable and rebuildable by our users, and for practical reasons to support further development of our packages (including security fixes). We already have an exception mechanism for handling bugs that shouldn't be RC for the current release because the actual impact of the bug turns out to be minor for some reason, or because they would have too negative of an impact on the release. Normally, how we handle this is to mark the bugs with an RC severity (serious in this case), and then, if the release team feels this package warrants a special exception, mark it as ignored for the current release. To me, that seems like the obvious approach to take here, and given the reasonably short list of bugs, I don't feel like that would cause unreasonable disruption. In the cases where the build failures are from flaky tests, I think disabling the test is a perfectly reasonable fix. If there is some significant merit to a test that fails in Santiago's environment but doesn't on the buildd network for some reason *and* has significant value in catching regressions on release architectures, that's an obvious case for an exception and could be handled like any other RC bug exception. I think we're going to keep getting lost in the weeds when we try to discuss this in general hypotheticals. If individual package maintainers request individual RC exceptions for their specific cases, the discussion can be far more concrete and in most cases will have an obvious outcome. So, to be explicit, my opinion (as just a Debian Developer, with no special ability to decide this, so just take this as another of the contributions to the thread) is that all of these bugs should be set to Severity: serious, and the maintainers can ask for stretch-ignore tags (or downgrades for their specific bug if that seems more correct for specific reasons related to their packge, whatever those may be) if they feel that is appropriate. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
