On Mon, Feb 20, 2017 at 04:42:49PM -0800, Russ Allbery wrote: > To say my opinion explicitly, since there's been a lot of discussion here, > some of which I've been involved in somewhat ambiguously: Thanks for writing this up, Russ. I fully agree with *everything* you said here: > 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. And with this "+1" mail I shall stop contributing to this thread. Everything has been said at least once :) Now let's deal with individual bugs and work on getting Stretch released eventually! -- cheers, Holger
Attachment:
signature.asc
Description: Digital signature