On Sun, May 24, 2015 at 11:42:31AM +1000, Stuart Prescott wrote: > Policy is, however, silent on whether that is the correct behaviour or not. > Clarifying policy as to what the correct behaviour should be seems to be a > necessary first step. I would expect that policy would end up saying > something > "should" (and not "must") happen with nocheck; I'm not sure that checking non- > mandatory things is sensible in this context.
As you point out below, changing policy certainly is a second step. Not the first one. > That said, the policy editors are often interested in seeing scope of the > impact of any change and the only way of knowing how many packages would be > made instabuggy by this change is to include it in the tests... Exactly. The only way to know whether this is a good change to policy is to try. If it happens to make lots of packages unreproducible, then we learned something and can revert to not varying nocheck. So give it a try and consider revert if it breaks the primary reproducible goal. Otherwise, profit from quicker testing. Helmut -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
