Fork me on GitHub

@plexus I made a few comments in the ticket. In my opinion all test failures should be considered “real”, and ought to be addressed by the submitter whose commit will break the build. For this to happen though, it’s important that Travis or CircleCI are set up to test pull requests prior to merging. There has to be a low-friction way for the submitter to know the build is now broken. And I know this will likely discourage new contributors. However, in my experience the only approach that scales is the one where everyone takes a part in maintaining clean builds.


I agree 100%, and in fact CIDER already builds the full test suite for pull requests, but we're in a situation where master is already red and has been for some time, so we need to fix that to get back to a situation where that build on a pull request means something.


Yes, understood.


Also, one more thing: one of the more common ways for builds to break is in eastwood or cljfmt. These are not as commonly used in personal projects, and contributors might not be used to seeing or dealing with the coding conventions enforced by those tools. Another source of discouragement for new contributors but as long as the tools are easy to run locally (in cider-nrepl it’s in the makefile, “make eastwood” or “make cljfmt”) then it’s possible to coach new contributors how to track down and resolve those format issues.