Santiago Vila <sanv...@unex.es> writes:
> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> even if they did not happen in buildd.debian.org yet?
This seems excessively aggressive. I've had FTBFS bugs in my packages
that were due to specific configurations for archive mass rebuilds that
were not reproducible on buildds, and while those are certainly bugs that
I wanted to fix, I think making them RC is questionable.
See, for instance:
https://bugs.debian.org/830452 (which I shouldn't have closed)
https://bugs.debian.org/835677
I understand the frustration -- for instance, I closed that first bug when
I absolutely should have left it open, since it represented a fragile
test. (It's now fixed properly.) But I think making them RC instead is
an overreaction.
Remember, making a bug RC says that we're going to remove the package from
the archive if the bug isn't fixed. Suppose either of those had been
reported near the release freeze and I was, say, in the hospital or
something and simply couldn't look at them. Would the appropriate
reaction to either of the above bugs be to remove the software from the
release?
Note that I'm not arguing that these aren't bugs, or that they shouldn't
be a priority, just that FTBFS bugs that aren't reproducible on buildds
don't interfere with the release or with security support and therefore
I'm not sure the RC severity is justified. (Now, that said, flaky
failures that sometimes do fail on buildds *may* interfere with security
support, and therefore are, to my mind, much more serious.)
--
Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>
