On Wed, Dec 21, 2016 at 07:26:59PM +0100, Julien Cristau wrote: > On Sun, Dec 18, 2016 at 12:21:19 +0100, Santiago Vila wrote: > > > Do you mean it's better not to have a common rule for these bugs and > > instead decide on a case by case basis? > > > > Could we please agree, at least, that this is RC in general and > > maintainers should ask for stretch-ignore tag? I don't think > > this is asking too much. > > > > The alternative is what it's currently happening: "Why bother to ask > > for permission to use stretch-ignore tag when you can always downgrade > > a RC bug to wishlist?" (Based on what they do, this is what some > > maintainers seem to think). > > > The common rule is that FTBFS is serious. Then there's the real world, > where e.g. some tests are timing-dependent and so don't always fail, but > having them is still better than not, so if the failure rate is low > enough I think a lower severity can make sense.
I think it would be better to use stretch-ignore for this, so that people do not take for granted that it's ok to fail randomly (to the point of not bothering to fix the problem). After all, we aim at having reproducible builds (some day), this does not only include generating identically .deb each time, but it also (implicitly) excludes random FTBFS failures. Then we would need to know: How much would be "low enough"? Apparently 50% of failure rate is good enough for some people. I consider this figure a terrible threshold, which is why I submitted this bug in the first place. I agree this threshold thing would be very "Salomonic", but IMO we should really be ensuring that packages build ok all the time (as part of the greater goal of being reproducible), not calculating the probability of failure. Thanks.
