From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-04-13 17:03:45
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk