A CVE (should there be a vulnerability in existing or a newly introduced dependency) will not be exposed during the CI build, but the build will fail if the CVE has severity 8 or above. To get the details, it will be necessary to run dependency check manually.

Thank you,

Vlad

On 10/24/17 16:27, Pramod Immaneni wrote:
There was a lot of discussion on this but looks like there was no final
agreement. Can you summarize what your PR does? Are we disclosing the
actual vulnerabilities as part of the automated build for every PR? That
would be a no-no for me. If it is something that requires manual steps, for
example as part of a release build, that would be fine.

On Mon, Oct 23, 2017 at 1:16 PM, Vlad Rozov <vro...@apache.org> wrote:

Please see https://github.com/apache/apex-core/pull/585 and APEXCORE-790.

Thank you,

Vlad


On 9/14/17 09:35, Vlad Rozov wrote:

Do you expect anything else from the community to recognize a
contribution other than committing it to the code line? Once there is a
steady flow of quality contributions, the community/PMC will recognize a
contributor by making that contributor a committer.

Thank you,

Vlad

On 9/12/17 13:05, Sanjay Pujare wrote:

For a vendor too, quality ought to be as important as security so I don't
think we disagree on the cost benefit analysis. But I get your drift.

By "creative incentive" I didn't imply any material incentive (although a
gift card would be nice :-)) but more along the lines of what a community
can do to recognize such contribution.

Sanjay

On Tue, Sep 12, 2017 at 8:10 AM, Vlad Rozov <vro...@apache.org> wrote:

I guess we have a different view on the benefit and cost definition. For
me the benefit of fixing CI build, flaky unit test, severe security
issue
is huge for the community and is possibly small (except for a security
issues) for a vendor.

By "creative" I hope you don't mean that other community members, users
and customers send a contributor a gift cards to compensate for the cost
:). For me PR that is blocked on a failed CI build is sufficiently
incentive for a contributor to look into why it fails and fixing it.

Thank you,

Vlad

On 9/11/17 23:58, Sanjay Pujare wrote:

I don't want to speak for others and I don't want to generalize. But an
obvious answer could be "cost-benefit analysis".

In any case we should come up with a creative way to "incentivize"
members
to do these tasks.



Reply via email to