On 4/10/2012 1:51 PM, Andrew Deason wrote: > On Tue, 10 Apr 2012 08:17:14 -0400 > Jeffrey Altman <jalt...@secure-endpoints.com> wrote: > >> What should not be done is turn on a new feature that *might* break >> the existing system and generate additional risk when the builders are >> 30 or 40 patchsets deep in builds. > > How is adding 'make check' as a non-failing step going to break > anything? Just only add it to the 'fast' builders, or put it on a > separate periodic (non-gerrit) build schedule.
What I said in reply to the "add as a non-failing step" proposal is that nobody is going to look for a failing step if it doesn't break the verification process. As such, doing so is pointless. If "make check" is going to be added, it must be add so that it fails the verification if it doesn't complete successfully. > Asking people to manually run the tests doesn't scale well, if there are > a bunch of things to fix and we keep asking them to try new patches. That is not what I said. To repeat it: Before "make check" is turned on for any builder, that builder's owner must perform "make check" manually to ensure that "make check" succeeds. This process doesn't have to scale. It is done at most once per active branch. Its no different than what I hope is done before a new builder is added to the requirements list. Adding a builder that doesn't build successfully because of a broken build environment has exactly the same impact. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
