On Wed, Jan 11, 2017 at 02:06:21PM -0500, Daniel Kahn Gillmor wrote: > (b) it's not actually an issue on the debian buildd infrastructure
While I understand the downgrade of this bug in particular, I'm worried about this rationale being used over and over again, when it's clearly flawed (and not just simply flawed, but seriously flawed). We don't wait for bugs to happen in buildd.debian.org. If we did, the hundreds of FTBFS bug reported by Lucas Nussbaum, Chris Lamb or even myself would have to be downgraded, as they only reference non-official build logs and not an official build log from buildd.debian.org. I'm also worried that buildd.debian.org sets the *only* bar for what we consider serious, when it's clearly not. Some examples: Packages having a missing "build-depends: gnupg", or, in general, any kind of missing build-depends) have a serious bug, even if gnupg or the missing build-dependency is still installed by default on buildd.debian.org. Packages which fail to build on single-CPU systems have a serious bug, even if all our autobuilders have more than one CPU. Packages having tests which fail on "slow" computers have a serious bug, even if all our autobuilders are "fast". Packages having tests which fail on very fast computers have a serious bug, even if all our autobuilders are just "fast". And so on. We can't just rely on specific and accidental features of buildd.debian.org to be present in any autobuilder, we can only rely on those who are expressed in build-depends. We don't have a Build-CPU-MHz: control field to ask for a fast autobuilder, but we should probably never have such control field. We don't have a Build-CPU: control field to ask for a multi-core autobuilder, but we should probably never have such control field. Etc. [ RAM size is a very different thing. Packages should use what they need, and autobuilders are always supposed to have "enough" ] > Please also see https://bugs.debian.org/850094 for more general > discussion of similar situations. So let's use my bug above as a rationale and not the "it does not fail on buildd.debian.org" one, please. Such rationale does not really match current practice. Sorry for the rant, I was thinking about writing these things some day in -devel as a way to reply to all the people who have downgraded bugs following such rationale which is not written in policy anywhere, so this email has accidantelly become a draft of such email. Thanks.
