Ian Jackson wrote...
> IMO all of these bugs should be RC. A randomly-reproducible build
> failure with more than negligible probabilty is likely to show up for
> some of Debian's users and downstreams and cause them mysterious
> trouble. It also causes trouble for stalwarts like Santiago, doing
> much needed and largely-unloved QA work.
Tracking down race conditions in the build that occur every now and then
only isn't joy either.
At least some of the packages have the random failures in the test
suite. If this justifies an RC, the maintainer will rather disable the
particular test, or even the entire test suite. Something I consider
the much worse scenario than having to trigger a rebuild.
Random build failures do happen, for reasons inside or outside the
packages. So downstream (also: security and point release builds) must
be prepared for a failing build anyway. Therefore I'd rather accept
random build failures, grudgingly, with the threshold set to somewhere
between 5% and 10%. Rationale: Build may fail one time, the second one
should very likely succeed then.
> If there is to be a failure probability threshold I would set it at
> 10^-4 or so. After all, computer time is cheap.
To determine 10^-4 with some accurance you'd have to rebuild that
package 20000 times. This is an amount where computer time isn't cheap
any longer.
Christoph
Attachment:
signature.asc
Description: Digital signature