On Thu, 29 Sep 2016, Michael Biebl wrote: > Sigh, you really like to argue [...]
No, I don't really like to argue. I was trying to be nice by explaining things with detail instead of moving the discussion to -devel, the technical committee or the release managers. If you just "don't like to argue", no problem, I will ask release managers to override your decision and everybody will be happy. As I have already explained, we don't wait for bugs to happen in buildd.debian.org before making them of serious severity. Examples here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org or here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org or even here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=sanvila%40debian.org Just count how many of those bugs have a reference to buildd.debian.org and how many of them have a reference to our own autobuilders (including the ones from reproducible builds). If any of us had to wait for FTBFS bugs to happen in buildd.debian.org, we would probably not file any bugs at all. (Not to mention nobody would file bugs about Arch:all packages, as many maintainers still do not upload in source-only form). So what you propose contradicts common practice *completely*. Instead, we file as "serious" any FTBFS which happens in a policy compliant autobuilder, i.e. any autobuilder which builds packages in the standard way (i.e. dpkg-buildpackage + fakeroot, not the weird example you tried to put as an example that "whatever happens in buildd.debian.org determines RC-ness"). Since you finally forwarded this upstream, I infer that you finally managed to reproduce this, at least once. Therefore, I ask again: Can we already make this bug serious (as it should be) or do you really need to check that my autobuilder is not misconfigured? > instead of actually addressing the issue The issue will be properly "addressed" when everybody can autobuild this package without failures, as explained by release policy. Hiding this problem by downgrading the severity is not "addressing the issue", and it's also against the definition of sarge-ignore. Thanks.
