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
signature.asc
Description: Digital signature
