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 >>>> >>>> >>>> >
