I'd add that if someone contributes a high quality PR, it's better for the community if the library maintainers accept it rather than reject it based only on gaps in a coverage report. On Mon, Apr 13, 2020 at 11:21 AM Edward Diener via Boost < boost@lists.boost.org> wrote:
On 4/13/2020 1:17 PM, Glen Fernandes via Boost wrote:
On Mon, Apr 13, 2020 at 12:44 PM Edward Diener via Boost
wrote: A number of libraries have code coverage/project tests in Github. I am not against such tests but I am against the idea that "failing" such a test, whatever that means, should prevent a PR from being merged into a Boost library.
Edward, are you referring to Boost libraries where a maintainer has specifically chosen to have Code Coverage part of the CI? Or are there libraries where the maintainer has not made this decision but their libraries CI automatically involve coverage because they use some shared CI configuration (boost-ci)?
I am just creating a valid PR for a Boost library. How that library uses code coverage is not my problem. I just do not want the validity of a PR being affected by how code coverage works for a library. I do realize that Github still allows a maintainer to merge a PR even when some CI testing fails. I just do not want code coverage, rather than correctness of code, determining whether a PR is merged or not. I am certainly not going to change a correct PR based on a code coverage report, unless that report shows me somehow that my change is logically incorrect, but I doubt that code coverage can do that.