On Mon, 20 Feb 2017 at 10:41:49 +0100, Santiago Vila wrote:
> You are somehow trying to equate RC-ness with "it FTBFS in buildd.debian.org".
No, I'm saying that a sufficiently repeatable FTBFS on buildd.debian.org
is effectively release-critical whether Policy says it is or not,
because if we can't build the package, we can't release it (or can't
release security updates for it later, or both).
There are many other forms of release-critical bug. Not all of them
are FTBFS, and (perhaps more controversially) not all FTBFS are
release-critical.
Is it a bug that the packages you're talking about sometimes fail
their tests? Absolutely. I'm not arguing that it isn't - it indicates
that either the code under test is wrong, or the test is wrong, or
perhaps even both. Given enough developer time, it should be fixed;
but given enough developer time, we'd have all sorts of nice things.
A release-critical bug is a really big hammer, and I think it's
important to distinguish between fixes we *want*, and fixes we *need*.
By asking for these bugs to be escalated to RC, you're essentially
saying that they are bad enough bugs that Debian would be a better
operating system for its users and developers if the affected packages
were removed than if they were left in unfixed; or if they have too
many dependencies to consider that, then you're essentially saying that
Debian 9 cannot be released until someone fixes those bugs. If Debian's
official infrastructure, which provides production binaries to our users,
can and does build these packages, then that seems like it might be
an exaggeration.
Again, I am not saying these bugs aren't bugs, merely that we have no
shortage of bugs, and perhaps some of the others are a more effective
use of our developers' limited supplies of time and patience.
> And the couterexample has been provided by yourself: Bugs about tzdata
> and lsb-base were declared RC by a Release Manager well before they
> were removed from buildds (thanks to Lucas Nussbaum).
Sure; the release managers made the judgement that those bugs
*are* problematic for the release. They make the release, they make
the rules for what they are willing to put in it.
> Does this mean we were doing an "academic exercise"?
In the case of tzdata and lsb-base, presumably they were removed from
buildd chroots because someone had a practical reason to want them to be;
and before they were removed, someone did the work to determine how
much fallout there was going to be, which is the best estimate we're
likely to get of the effort required to fix that fallout.
Without knowing the circumstances in detail, I don't know whether
the effort/benefit trade-off between the effort required to fix those
bugs was worth the benefit we derived from removing those packages
from the minimal chroot. Someone presumably concluded that it was
worth it. If the conclusion had been that it wasn't worth it, then
the answer would have instead been to add tzdata or lsb-base
to Essential, Build-Essential or some similar set of
guaranteed/assumed packages.
S
