Subject: Re: [boost] Seems like I need write-access to merge a PR
From: James E. King, III (jking_at_[hidden])
Date: 2017-10-25 19:50:53
On Wed, Oct 25, 2017 at 3:36 PM, Vinnie Falco via Boost <
> On Wed, Oct 25, 2017 at 12:12 PM, James E. King, III via Boost
> <boost_at_[hidden]> wrote:
> > Doesn't this defeat the purpose of using Appveyor and Travis, or do you
> > additional tests that take too long for CI builds to be useful? If you
> > keep some tests to yourself, the process of vetting new code changes
> from outside
> > becomes unmaintainable.
> My motto is "Trust in God, but always run the tests locally." There
> are security considerations here, so I make sure that my workflow
> always brings external submissions through my own machine where I can
> inspect it with a debugger and my own two eyes. I am strongly opposed
> to any "farm to market" system since that could lead to being lazy.
Sounds like, "write once, debug everywhere". :)
This development philosophy makes sense to me for a new project. It is not
into maintenance mode during which other folks are typically enabled. For
if the CMT picked up a project which had no CI builds and no measurement of
coverage on the unit tests, and they don't have the secret formula that the
was using to vet code changes, they have to reinvent the wheel. If however
original author sets up a robust CI environment with code coverage metrics,
would be able to understand what expectations for quality submissions are
at a minimum.
This can be further improved with static code analysis (cppcheck, Coverity
well as -fsanitize type builds and valgrind-type builds.
What I said previously is not intended as a replacement for a thorough code
Someone should always inspect every line of code change for security,
and performance related issues. If we all make as much of our baseline
requirements as automated as possible, the maintainability of the entire
going into the future becomes easier.
We are certainly aligned on providing quality product, no matter what the
I think everyone would agree this is good for any project.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk