Mailing-List: contact dev-help@apex.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@apex.apache.org
MIME-Version: 1.0
In-Reply-To: <137f5475-4c3b-30da-81f4-be18d36b4834@apache.org>
References: <f6a88b3e-3fb0-6e63-1514-83d0ff50c1b1@gmail.com>
 <39e50723-9e96-a1dd-590b-c74394535f88@apache.org> <CAA7LveEUWRWTRVwNv3C2Y_VuU+EeuinMy3dYTpqo02PekmGjVQ@mail.gmail.com>
 <CA+5xAo1moEr=O8FyBzCTkG96WYp3NOsaZRW_kFjuLjGZXCYj_Q@mail.gmail.com>
 <61435004-3760-6b41-e859-e7dc38a9eae1@apache.org> <CAA7LveF+J69aJCNJBn4Fa7d+S1zTZk871G5f9QBUumGDeEXxBw@mail.gmail.com>
 <CALPtS-KFDW8BQS6GqGV8fDkFivFyS_CTv1OYq9znSPEoRWEUpA@mail.gmail.com>
 <69269b43-aa7a-f46a-acec-a884f66e1ca8@apache.org> <CAKt=akHVz=_VNRTeS4_ux2jHnuPf0pFjRsL75Ab1J0WwENK0HA@mail.gmail.com>
 <c542d182-62ba-5371-d9e3-308507762caf@apache.org> <CALPtS-JPcDREXO7K5ucDmX5K2DH1RhTvdL51GYxcPMFWYFvVUA@mail.gmail.com>
 <1990549a-78c3-8e44-d9f3-a6522d02a998@apache.org> <CALPtS-KAsdK41Yj-wOMzWC4Geor-OCac-rgDmR4DH0jC6bj+hA@mail.gmail.com>
 <2e34f475-76ae-c431-137d-bc7b74e930d4@apache.org> <CALPtS-JVwdXx_3oSYiOQjv4XPpLeFyFgjeKkvzmCJBt0NTFm+Q@mail.gmail.com>
 <38f17606-cc31-44a7-d616-c8e86e996b3d@apache.org> <137f5475-4c3b-30da-81f4-be18d36b4834@apache.org>
From: Pramod Immaneni <pramod@datatorrent.com>
Date: Tue, 24 Oct 2017 16:27:05 -0700
Message-ID: <CAA7LveFN0A3CAAhVYZb74ob_uLdTH+KUJ3_ry8iPWeH6uDdEDA@mail.gmail.com>
Subject: Re: checking dependencies for known vulnerabilities
To: dev@apex.apache.org
Content-Type: multipart/alternative; boundary="94eb2c1c00a6c5a3a2055c534881"
archived-at: Tue, 24 Oct 2017 23:27:42 -0000

--94eb2c1c00a6c5a3a2055c534881
Content-Type: text/plain; charset="UTF-8"

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 <vrozov@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 <vrozov@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.
>>>>>
>>>>>
>>
>

--94eb2c1c00a6c5a3a2055c534881--