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
