On Mon, Apr 13, 2020 at 9:53 AM Andrey Semashev via Boost
I agree. I consider code coverage and similar tools informative at best. Therefore they should not block a commit or a PR merge.
Well, I think that depends on the situation. If a contributor submits a pull request to add some new public member functions for example, and they don't write the tests then the coverage will go down. Or if they do write the tests but they are incomplete, the coverage can also go down. I think it is entirely reasonable in this case, rather than merge the pull request simply to ask "why did coverage go down?" If a project has set up the coverage reports correctly, and adopted a coding style that enhances the precision of the reports, then soft failures of reduced coverage on pull requests become much more meaningful. I agree that for this specific pull request (https://github.com/boostorg/property_map/pull/13) that coverage decrease should not hold up anything, because this project is not set up for success with coverage reports in the first place. Regards