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.
On Mon, Sep 11, 2017 at 10:59 PM, Vlad Rozov <vro...@apache.org> wrote:
So, you are saying that those members are eager to see new features, new
functionalities and new code added to the project? Why they are not eager
to see a unit test being fixed or a dependency with a severe security risk
being removed? It is not that their original PR would be closed as a result
of a unit test fix. What prevents those community members to put time and
effort to fix CI build (unit test, dependency) that will directly benefit
the community but may not immediately benefit a vendor and its (paying)
customers?
Thank you,
Vlad
On 9/11/17 22:08, Sanjay Pujare wrote:
Comments inline:
On 9/10/17 23:40, Priyanka Gugale wrote:
It's good idea to check for vulnerabilities, but as Pramod said all
softwares / libraries are going to have some or other vulnerability at
any
time. I will go with approach of "let's discuss this addition" and we
should not affect PRs which are not adding any new dependencies (due to
old
vulnerabilities).
While all software/libraries are subject to insecure code and
vulnerabilities, all software vendors whether open or close source
hopefully try to make code more secure rather than insecure. If there is
an
existing or newly introduced dependency with a critical security issue, I
don't see why Apex community wants to accept the high probability of
being
exposed to a security exploit. The only reasonable explanation for me is
that the community members do not care about overall project quality and
care only for tasks/PRs assigned to them by somebody else. I'll be glad
to
hear a different explanation for the proposal not to penalize PRs that do
not introduce new dependencies and are affected by a newly found
vulnerability in an existing dependency. Will not we all be penalized
later
if we don't fix it?
I take exception to the insinuation that (some) community members "care
only for tasks/PRs assigned to them by somebody else". It is quite
possible
or likely that these members are eager to see new features, new
functionalities, or new code added to the project because they get excited
by such things. You need to take into account the mindset of people who
are
submitting PRs to add a new functionality or fix a bug. The PR author's
focus correctly is on addressing that particular JIRA and ensuring that
JIRA gets resolved at the highest quality. To burden that PR author with
unrelated considerations of build systems, vulnerability findings and such
is not fair. Note that the project is (or should be) primarily driven by
users (and customers in case of vendors shipping this code in products)
who
use these features and pay for these features. So we need to balance the
long term concerns about "security issues" and quality with the immediate
term concerns about adding features and functionalities.
Also I also strongly feel, we need to be meticulous and think it through
before introducing such checks for reasons discussed before.
+1. Equally applies to a newly introduced functionality and bug fixes.
Totally agree. However when we discuss or "think through" any concerns
they
should apply to the issue at hand (i.e. the newly introduced functionality
and bug fixes) and not external factors.
-Priyanka
