Scribit Lars Wirzenius dies 06/04/2005 hora 21:34: > > I don't find it very sane to be forced to deliberately trigger > > problems on the user's system to find bugs. > I assume the goal is to make it fail on the developer's system, on > build daemons, whenever random developers unpack the package If it is random, there could be only one or two combinations that fail and dozens (or far more, FWIW) that work well without anyone noticing anything. Remember that when it can go wrong, it will at the worst moment; that is, for us, on the user's system (and for the source point of view, random developers should be considered users). The maintainer and the buildds count only for a bit more than a dozen unpackings, for now, if I understand correctly how buildds work... > The point is to make it as likely as possible to make it break, if it > breaks at all, so that when the user sees the package, it is already > non-broken. That's the very purpose of a test suite! But that one doesn't rely on the randomness of the apparition of a bug, but makes *everything* that is possible to make it visible. -1 random +2 lintian Why use a suboptimal solution when an optimal one is available? Probabilistically, Nowhere man -- nowhere.man@levallois.eu.org OpenPGP 0xD9D50D8A
Attachment:
signature.asc
Description: Digital signature