Check as part of PR build is needed to ensure no new issues are introduced. I don't think it is necessary to have another build to notice pre-existing issues since releases won't occur without prior PRs.
Whitelisting suggestion is for pre-existing problems and not for those introduced by a PR. On Thu, Nov 2, 2017 at 11:35 PM, Pramod Immaneni <pra...@datatorrent.com> wrote: > If the PR introduces a CVE by all means lets fail it initally and later > look at whitelisting it if needed. Why fail all PRs that haven't caused the > problem. What happens when there are no PRs in a given period, wouldn't it > be better to know above crtiical CVEs (that this proposal is trying to > address) sooner than wait till some random PR is raised. What if there are > no PRs for a month. I think it makes sense to have a separate build that > will catch these errors. > > On Thu, Nov 2, 2017 at 3:17 PM, Ananth G <ananthg.a...@gmail.com> wrote: > > > Only the first PR should be broken if cve with a higher score than agreed > > is introduced .Once you whitelist subsequent builds will not fail? > > > > - The dependency check plugin is enabled to fail/break the build if a > > violation is detected > > - A PR introducing a risk will either “acknowledge” the cve by creating > > the whitelist entry as part of the process or will break the build > > - The reviewer/s would notice either the changes to the whitelist file or > > the build break > > - The review process would agree upon the approach and ensure JIRA ticket > > creation or question why an alternative cannot be used > > - whitelist would be maintained in a suppressions file example given here > > https://jeremylong.github.io/DependencyCheck/general/suppression.html > > - subsequent PR update should no longer break the build > > - there is a list of JIRA items for cve which needs to be addressed in > the > > subsequent releases as well as a set of artefacts in the project modules > > that summarise the community’s awareness of the issue. > > > > > > Regards > > Ananth > > > > > On 3 Nov 2017, at 8:38 am, Pramod Immaneni <pra...@datatorrent.com> > > wrote: > > > > > > The question is which build? We can definitely make it a mandatory > > release > > > step and also have nightly builds that are meant for just these, > > detection > > > of CVEs and even possible infra changes that might break tests. Those > > will > > > work even if there are no PRs. > > > > > >> On Thu, Nov 2, 2017 at 1:21 PM, Ananth G <ananthg.a...@gmail.com> > > wrote: > > >> > > >> My vote would be to break the build. This can then force a > > “whitelisting” > > >> configuration in the maven plugin to be created as part of the review > > >> process ( along with a new JIRA ticket ). > > >> > > >> The concern would then be to ensure that the community works towards a > > >> resolution of the JIRA. Not breaking the build for me is tech debt > > slipping > > >> without anyones notice. Fixing the JIRA is a hygiene process which I > > >> believe cannot take a back burner as compared contributor welfare and > > would > > >> need commitments from the contributor ( and/or others). > > >> > > >> On a related note, looking at apache spark, there seems to be CVE > > listings > > >> which the spark community has taken care of as the releases > progressed. > > >> http://www.cvedetails.com/vulnerability-list/vendor_id- > > >> 45/product_id-38954/Apache-Spark.html <http://www.cvedetails.com/ > > >> vulnerability-list/vendor_id-45/product_id-38954/Apache-Spark.html> . > > >> > > >> Regards, > > >> Ananth > > >> > > >> > > >>> On 3 Nov 2017, at 4:48 am, Sanjay Pujare <san...@datatorrent.com> > > wrote: > > >>> > > >>> I like this suggestion. Blocking the PR is too drastic. I also second > > >>> Pramod's point (made elsewhere) that we should try to encourage > > >>> contribution instead of discouraging it by resorting to drastic > > measures. > > >>> If you institute drastic measures to achieve a desired effect (e.g. > > >> getting > > >>> contributors to look into CVEs and build infrastructure issues) it > can > > >> have > > >>> the opposite effect of contributors losing interest. > > >>> > > >>> Sanjay > > >>> > > >>> > > >>> > > >>>> On Wed, Nov 1, 2017 at 1:25 PM, Thomas Weise <t...@apache.org> > wrote: > > >>>> > > >>>> Considering typical behavior, unless the CI build fails, very few > will > > >> be > > >>>> interested fixing the issues. > > >>>> > > >>>> Perhaps if after a CI failure the issue can be identified as > > >> pre-existing, > > >>>> we can whitelist and create a JIRA that must be addressed prior to > the > > >> next > > >>>> release? > > >>>> > > >>>> > > >>>> On Wed, Nov 1, 2017 at 7:51 PM, Pramod Immaneni < > > pra...@datatorrent.com > > >>> > > >>>> wrote: > > >>>> > > >>>>> I would like to hear what others think.. at this point I am -1 on > > >> merging > > >>>>> the change as is that would fail all PR builds when a matching CVE > is > > >>>>> discovered regardless of whether the PR was the cause of the CVE or > > >> not. > > >>>>> > > >>>>>> On Wed, Nov 1, 2017 at 12:07 PM, Vlad Rozov <vro...@apache.org> > > wrote: > > >>>>>> > > >>>>>>> On 11/1/17 11:39, Pramod Immaneni wrote: > > >>>>>>> > > >>>>>>> On Wed, Nov 1, 2017 at 11:36 AM, Vlad Rozov <vro...@apache.org> > > >>>> wrote: > > >>>>>>> > > >>>>>>> There is no independent build and the check is still necessary to > > >>>>> prevent > > >>>>>>>> new dependencies with CVE being introduced. > > >>>>>>>> > > >>>>>>>> There isn't one today but one could be added. What kind of > effort > > is > > >>>>>>> needed. > > >>>>>>> > > >>>>>> After it is added, we can discuss whether it will make sense to > move > > >>>> the > > >>>>>> check to the newly created build. Even if one is added, the check > > >> needs > > >>>>> to > > >>>>>> be present in the CI builds that verify PR, so it is in the right > > >> place > > >>>>>> already, IMO. > > >>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> Look at Malhar 3.8.0 thread. There are libraries from Category X > > >>>>>>>> introduced as a dependency, so now instead of dealing with the > > issue > > >>>>> when > > >>>>>>>> such dependencies were introduced, somebody else needs to deal > > with > > >>>>>>>> removing/fixing those dependencies. > > >>>>>>>> > > >>>>>>>> Those were directly introduced in PRs. I am not against adding > > >>>>> additional > > >>>>>>> checks that verify the PR better. > > >>>>>>> > > >>>>>> Right and it would be much better to catch the problem at the time > > it > > >>>> was > > >>>>>> introduced, but Category X list (as well as known CVE) is not > > static. > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> Thank you, > > >>>>>>>> > > >>>>>>>> Vlad > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 11/1/17 11:21, Pramod Immaneni wrote: > > >>>>>>>> > > >>>>>>>> My original concern still remains. I think what you have is > > valuable > > >>>>> but > > >>>>>>>>> would prefer that it be activated in an independent build that > > >>>>> notifies > > >>>>>>>>> the > > >>>>>>>>> interested parties. > > >>>>>>>>> > > >>>>>>>>> On Wed, Nov 1, 2017 at 11:13 AM, Vlad Rozov <vro...@apache.org > > > > >>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> Any other concerns regarding merging the PR? By looking at the > > >>>> active > > >>>>>>>>> PRs > > >>>>>>>>> > > >>>>>>>>>> on the apex core the entire conversation looks to be at the > moot > > >>>>> point. > > >>>>>>>>>> > > >>>>>>>>>> Thank you, > > >>>>>>>>>> > > >>>>>>>>>> Vlad > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> On 10/30/17 18:50, Vlad Rozov wrote: > > >>>>>>>>>> > > >>>>>>>>>> On 10/30/17 17:30, Pramod Immaneni wrote: > > >>>>>>>>>> > > >>>>>>>>>>> On Sat, Oct 28, 2017 at 7:47 AM, Vlad Rozov < > vro...@apache.org > > > > > >>>>>>>>>>> wrote: > > >>>>>>>>>>> > > >>>>>>>>>>>> Don't we use unit test to make sure that PR does not break > an > > >>>>>>>>>>>> existing > > >>>>>>>>>>>> > > >>>>>>>>>>>> functionality? For that we use CI environment that we do not > > >>>>> control > > >>>>>>>>>>>>> and do > > >>>>>>>>>>>>> not introduce any changes to, but for example Apache > > >>>>> infrastructure > > >>>>>>>>>>>>> team > > >>>>>>>>>>>>> may decide to upgrade Jenkins and that may impact Apex > > builds. > > >>>> The > > >>>>>>>>>>>>> same > > >>>>>>>>>>>>> applies to CVE. It is there to prevent dependencies with > > severe > > >>>>>>>>>>>>> vulnerabilities. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> Infrastructure changes are quite different, IMO, from this > > >>>>> proposal. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> While > > >>>>>>>>>>>> they are not in our control, in majority of the cases, the > > >>>> changes > > >>>>>>>>>>>> maintain > > >>>>>>>>>>>> compatibility so everything on top will continue to run the > > >> same. > > >>>>> In > > >>>>>>>>>>>> this > > >>>>>>>>>>>> case a CVE will always fail all PRs, the code changes have > > >>>> nothing > > >>>>> to > > >>>>>>>>>>>> do > > >>>>>>>>>>>> with introducing the CVE. I did make the exception that if a > > PR > > >>>> is > > >>>>>>>>>>>> bringing > > >>>>>>>>>>>> in the CVE yes do fail it. > > >>>>>>>>>>>> > > >>>>>>>>>>>> There were just two recent changes, one on Travis CI side > and > > >>>>> another > > >>>>>>>>>>>> > > >>>>>>>>>>> on > > >>>>>>>>>>> Jenkins side that caused builds for all PRs to fail and none > of > > >>>> them > > >>>>>>>>>>> was > > >>>>>>>>>>> caused by code changes in any of open PRs, so I don't see how > > it > > >>>> is > > >>>>>>>>>>> different. > > >>>>>>>>>>> > > >>>>>>>>>>> A code change may or may not have relation to CVE introduced. > > For > > >>>>>>>>>>> newly > > >>>>>>>>>>> introduced dependencies, there may be known CVEs. In any > case I > > >>>>> don't > > >>>>>>>>>>> think > > >>>>>>>>>>> it is important to differentiate how CVE is introduced, it is > > >>>>>>>>>>> important > > >>>>>>>>>>> to > > >>>>>>>>>>> eliminate dependencies with known CVEs. > > >>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>>>>> There is no "stick" in a failed build or keeping PR open > until > > >>>>>>>>>>>> dependency > > >>>>>>>>>>>> > > >>>>>>>>>>>> issue is resolved or unit test failure is fixed. Unless an > > >>>> employer > > >>>>>>>>>>>>> punishes its employee for not delivering PR based on that > > >> vendor > > >>>>>>>>>>>>> priority, > > >>>>>>>>>>>>> there is no "stick". As we already discussed, the community > > >> does > > >>>>> not > > >>>>>>>>>>>>> have a > > >>>>>>>>>>>>> deadline for a PR merge or for a release to go out. In a > case > > >>>>> there > > >>>>>>>>>>>>> is a > > >>>>>>>>>>>>> problematic dependency (with CVE or category X license) you > > as > > >> a > > >>>>> PMC > > >>>>>>>>>>>>> suppose to -1 a release (at least I will). Will you > consider > > -1 > > >>>>> as a > > >>>>>>>>>>>>> "stick"? For me, it is not about punishing an individual > > >>>>>>>>>>>>> contributor, > > >>>>>>>>>>>>> it is > > >>>>>>>>>>>>> a priority and focus shift for the entire community, not a > > >>>> "stick" > > >>>>>>>>>>>>> for > > >>>>>>>>>>>>> an > > >>>>>>>>>>>>> individual contributor. > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> The stick I am referring to is failing all PRs hoping that > > will > > >>>>> make > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> people > > >>>>>>>>>>>> address CVEs. It's got nothing to do with an employer, > people > > >>>>>>>>>>>> contributing > > >>>>>>>>>>>> to open source can't expect they can control what the > outcome > > >>>> will > > >>>>> be > > >>>>>>>>>>>> or > > >>>>>>>>>>>> what form it will take. You may be confusing this with some > > >> other > > >>>>>>>>>>>> issue. > > >>>>>>>>>>>> In > > >>>>>>>>>>>> some of the arguments, you are assuming this scenario is > > similar > > >>>> to > > >>>>>>>>>>>> build > > >>>>>>>>>>>> failures from failing unit tests and I am arguing that > > premise. > > >> I > > >>>>>>>>>>>> don't > > >>>>>>>>>>>> think we should bring regular development to a halt > whenever a > > >>>>>>>>>>>> matching > > >>>>>>>>>>>> CVE > > >>>>>>>>>>>> is discovered, unless there is some other secondary reason > > like > > >>>>>>>>>>>> merging a > > >>>>>>>>>>>> PR will make it difficult for a CVE fix to be made. Have you > > >>>> given > > >>>>> a > > >>>>>>>>>>>> thought to what I said about having a separate build that > will > > >>>>> notify > > >>>>>>>>>>>> about > > >>>>>>>>>>>> CVEs. > > >>>>>>>>>>>> > > >>>>>>>>>>>> As I mentioned, there is no stick, no deadlines and no > issues > > >>>>> keeping > > >>>>>>>>>>>> > > >>>>>>>>>>> PRs > > >>>>>>>>>>> open until builds can be verified on CI environment. Fixing a > > >>>> failed > > >>>>>>>>>>> build > > >>>>>>>>>>> is a priority for the *community* not a stick for an > individual > > >>>>>>>>>>> contributor. > > >>>>>>>>>>> > > >>>>>>>>>>> I don't see why keeping PRs open (for whatever reason) brings > > >>>>> regular > > >>>>>>>>>>> development to a halt. Nobody is going to put github repo > > >> offline. > > >>>>>>>>>>> Contributors may continue to open new PR, collaborate on > > existing > > >>>>> PRs > > >>>>>>>>>>> and > > >>>>>>>>>>> add more changes (and need to be patient for those changes to > > be > > >>>>>>>>>>> reviewed > > >>>>>>>>>>> and accepted). The regular development will continue with the > > >> only > > >>>>>>>>>>> exception that the next commit to be merged must address the > > >> build > > >>>>>>>>>>> issue > > >>>>>>>>>>> (whether it is a failed unit test or newly found CVE). > > >>>>>>>>>>> > > >>>>>>>>>>> I don't see much value in a separate build and do not plan to > > put > > >>>>>>>>>>> effort > > >>>>>>>>>>> in that direction. Additionally, will not a separate build > that > > >>>> only > > >>>>>>>>>>> checks > > >>>>>>>>>>> for CVE will trigger your initial concern of disclosing CVE > in > > >>>>> public? > > >>>>>>>>>>> > > >>>>>>>>>>> Thank you, > > >>>>>>>>>>> > > >>>>>>>>>>>> Vlad > > >>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On 10/27/17 14:28, Pramod Immaneni wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>> On Fri, Oct 27, 2017 at 11:51 AM, Vlad Rozov < > > >> vro...@apache.org > > >>>>> > > >>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>> > > >>>>>>>>>>>>>> On 10/26/17 11:46, Pramod Immaneni wrote: > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 10:39 AM, Vlad Rozov < > > >>>> vro...@apache.org> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I guess you are mostly concerned regarding new CVE in an > > >>>>> existing > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> dependency. Once such CVE is added to a database, will > it > > be > > >>>>>>>>>>>>>>>> better > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>> know > > >>>>>>>>>>>>>>>>> about it or postpone discovery till we cut release > > >>>> candidate? > > >>>>> In > > >>>>>>>>>>>>>>>>> case > > >>>>>>>>>>>>>>>>> it > > >>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>> reported only during release cycle, there is much less > > time > > >>>>> for > > >>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>> community to take an action and it still needs to be > > taken > > >>>>> (as a > > >>>>>>>>>>>>>>>>> PMC > > >>>>>>>>>>>>>>>>> member > > >>>>>>>>>>>>>>>>> you are responsible for preventing release with severe > > >>>>> security > > >>>>>>>>>>>>>>>>> issue > > >>>>>>>>>>>>>>>>> going > > >>>>>>>>>>>>>>>>> out). If it is reported once the information becomes > > >>>>> available, > > >>>>>>>>>>>>>>>>> there > > >>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>> more time to research and either upgrade the dependency > > >> with > > >>>>>>>>>>>>>>>>> newly > > >>>>>>>>>>>>>>>>> found > > >>>>>>>>>>>>>>>>> CVE, agree that it does not impact the project. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> This would be the more commonly occurring scenario. We > > can > > >>>>>>>>>>>>>>>>> always > > >>>>>>>>>>>>>>>>> know > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> about the CVEs because of your changes. We don't need > to > > >>>> fail > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> builds to > > >>>>>>>>>>>>>>>> do > > >>>>>>>>>>>>>>>> that. I am not asking you to remove the reporting. There > > is > > >>>> no > > >>>>>>>>>>>>>>>> set > > >>>>>>>>>>>>>>>> time > > >>>>>>>>>>>>>>>> for > > >>>>>>>>>>>>>>>> a release so having less time during release for > > addressing > > >>>>>>>>>>>>>>>> relevant > > >>>>>>>>>>>>>>>> CVEs > > >>>>>>>>>>>>>>>> does not come up. There is also nothing preventing > anyone > > >>>> from > > >>>>>>>>>>>>>>>> looking > > >>>>>>>>>>>>>>>> at > > >>>>>>>>>>>>>>>> these reports and taking action earlier. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> I don't see why it will be more commonly occurring > > scenario, > > >>>>> but > > >>>>>>>>>>>>>>>> I > > >>>>>>>>>>>>>>>> think > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> it is equally important to prevent new dependency with > > >> severe > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> vulnerabilities being introduced into the project and > check > > >>>>>>>>>>>>>>> existing > > >>>>>>>>>>>>>>> dependencies for newly discovered severe vulnerabilities. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> How will we know about CVE if it is removed from CI > build? > > >> Why > > >>>>>>>>>>>>>>> require > > >>>>>>>>>>>>>>> manual verification when it can be done during CI build > and > > >>>> does > > >>>>>>>>>>>>>>> not > > >>>>>>>>>>>>>>> affect > > >>>>>>>>>>>>>>> builds done by individual contributors? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> While there is no set time for a release, there is no set > > >> time > > >>>>>>>>>>>>>>> for a > > >>>>>>>>>>>>>>> PR > > >>>>>>>>>>>>>>> merge as well. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> Yes, nothing prevents anyone from looking at the > dependency > > >>>>>>>>>>>>>>> vulnerabilities, but there is a better chance that > "anyone" > > >>>> does > > >>>>>>>>>>>>>>> not > > >>>>>>>>>>>>>>> mean > > >>>>>>>>>>>>>>> nobody if CI build fails. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I still do not understand why you value an individual > > >>>>> contributor > > >>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> PR > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> over the community and the project itself. Once there > is a > > >>>>> severe > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> security > > >>>>>>>>>>>>>>>>> vulnerability, it affects everyone who cares about the > > >>>>> project, > > >>>>>>>>>>>>>>>>> including > > >>>>>>>>>>>>>>>>> all contributors. I don't see a problem with a PR being > > in > > >> a > > >>>>>>>>>>>>>>>>> pending > > >>>>>>>>>>>>>>>>> (not > > >>>>>>>>>>>>>>>>> merged) open state till a build issue is resolved. > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> That is a mischaracterization that you have stated > before > > >> as > > >>>>>>>>>>>>>>>>> well. A > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> project cannot grow without contributions and without > > >>>> policies > > >>>>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> create > > >>>>>>>>>>>>>>>> a supportive enviroment where that can happen, I don't > see > > >>>> the > > >>>>>>>>>>>>>>>> need > > >>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>> put > > >>>>>>>>>>>>>>>> unnecessary obstacles for legitimate contributions that > > are > > >>>> not > > >>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>> cause > > >>>>>>>>>>>>>>>> of a problem. Everytime there is a matching CVE the PRs > > are > > >>>>> going > > >>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>> get > > >>>>>>>>>>>>>>>> blocked till that CVE is addressed and I am not > confident > > we > > >>>>> have > > >>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>> bandwidth in the community to address this expediently. > It > > >> is > > >>>>>>>>>>>>>>>> also > > >>>>>>>>>>>>>>>> inaccurate to equate this to PR not being merged till > > build > > >>>>>>>>>>>>>>>> issues > > >>>>>>>>>>>>>>>> are > > >>>>>>>>>>>>>>>> resolved as it derives from an assumption that CVE is > same > > >>>> as a > > >>>>>>>>>>>>>>>> build > > >>>>>>>>>>>>>>>> failure. > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> While project can't grow without individual > contributions, > > >>>>>>>>>>>>>>>> project > > >>>>>>>>>>>>>>>> is a > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> result of a large number of contributions from a number > of > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> contributors. > > >>>>>>>>>>>>>>> Some of those contributors are not active anymore and > will > > >> not > > >>>>>>>>>>>>>>> provide > > >>>>>>>>>>>>>>> any > > >>>>>>>>>>>>>>> fixes should a vulnerability be found in their > > contribution. > > >>>> It > > >>>>>>>>>>>>>>> becomes a > > >>>>>>>>>>>>>>> shared responsibility of all currently active community > > >>>> members > > >>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>> those > > >>>>>>>>>>>>>>> who submit PR are part of the community and share that > > >>>>>>>>>>>>>>> responsibility, > > >>>>>>>>>>>>>>> are > > >>>>>>>>>>>>>>> not they? If a contributor considers him/herself as part > > of a > > >>>>>>>>>>>>>>> community, > > >>>>>>>>>>>>>>> why he or she can't wait for the build issue to be > resolved > > >> or > > >>>>>>>>>>>>>>> better > > >>>>>>>>>>>>>>> take > > >>>>>>>>>>>>>>> an action on resolving the issue? The only possible > > >>>> explanation > > >>>>>>>>>>>>>>> that I > > >>>>>>>>>>>>>>> see > > >>>>>>>>>>>>>>> is the one that I already mentioned on this thread. > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> If you see this as unnecessary obstacles for legitimate > > >>>>>>>>>>>>>>> contributions, > > >>>>>>>>>>>>>>> why > > >>>>>>>>>>>>>>> to enforce code style, it is also unnecessary obstacle. > > Unit > > >>>>> test? > > >>>>>>>>>>>>>>> Should > > >>>>>>>>>>>>>>> it be considered to be optional for a PR to pass unit > tests > > >> as > > >>>>>>>>>>>>>>> well? > > >>>>>>>>>>>>>>> What > > >>>>>>>>>>>>>>> if an environment change on CI side causes build to fail > > >>>> similar > > >>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>> what > > >>>>>>>>>>>>>>> happened recently? Should we disable CI builds too and > rely > > >>>> on a > > >>>>>>>>>>>>>>> committer > > >>>>>>>>>>>>>>> or a release manager to run unit tests? If CI build > fails > > >> for > > >>>>>>>>>>>>>>> whatever > > >>>>>>>>>>>>>>> reason, how can you be sure that if it fails for another > PR > > >> as > > >>>>>>>>>>>>>>> well, > > >>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>> they both fail for the same reason and there is no any > > other > > >>>>>>>>>>>>>>> reasons > > >>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>> will cause a problem with a PR? > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> I don't know how failing PRs because of CVE, which we > don't > > >>>>>>>>>>>>>>> introduce, > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> don't control, no idea of and possibly unrelated would > fall > > >> in > > >>>>> the > > >>>>>>>>>>>>>> same > > >>>>>>>>>>>>>> bucket as unit tests. I am at a loss of words for that. > > There > > >>>> is > > >>>>> no > > >>>>>>>>>>>>>> reason > > >>>>>>>>>>>>>> to block legitimate development for this. This can be > > handled > > >>>>>>>>>>>>>> separtely > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>> in parallel. Maybe there is a way we can setup an > > independent > > >>>> job > > >>>>>>>>>>>>>> on > > >>>>>>>>>>>>>> a > > >>>>>>>>>>>>>> build server that runs nightly, fails if there are new > CVEs > > >>>>>>>>>>>>>> discovered > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>> sends an email out to the security or dev group. You could > > >> even > > >>>>>>>>>>>>>> reduce > > >>>>>>>>>>>>>> the > > >>>>>>>>>>>>>> CVE threshold for this. I don't believe in a stick > approach > > >>>>> (carrot > > >>>>>>>>>>>>>> and > > >>>>>>>>>>>>>> stick metaphor) and believe in proportional measures. > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Thank you, > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>>> Vlad > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> On 10/26/17 09:42, Pramod Immaneni wrote: > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> On Thu, Oct 26, 2017 at 12:08 AM, Vlad Rozov < > > >>>>> vro...@apache.org > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> There is a way to add an exception, but it needs to be > > >>>>> discussed > > >>>>>>>>>>>>>>>>> on > > >>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>> a > > >>>>>>>>>>>>>>>>>> case > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> by case basis. Note that CVEs are not published until > a > > >> fix > > >>>>> is > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> available. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> For severity 8 CVEs I expect patches to become > > available > > >>>> for > > >>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>> reported > > >>>>>>>>>>>>>>>>>>> version unless it is an obsolete version in which > case, > > >>>> the > > >>>>>>>>>>>>>>>>>>> upgrade > > >>>>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>> a > > >>>>>>>>>>>>>>>>>>> supported version is already overdue. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> I think we should retain the ability to make that > > choice > > >>>> of > > >>>>>>>>>>>>>>>>>>> what > > >>>>>>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>>>> when > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> to upgrade rather than hard enforce it. Like I > > mentioned > > >>>> the > > >>>>>>>>>>>>>>>>>>> CVE > > >>>>>>>>>>>>>>>>>>> may > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> not > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> apply to us (it has happened before), even though it > may > > >> be > > >>>>>>>>>>>>>>>>>> beneficial > > >>>>>>>>>>>>>>>>>> upgrade generally when its not applicable, there may > not > > >> be > > >>>>> the > > >>>>>>>>>>>>>>>>>> bandwidth > > >>>>>>>>>>>>>>>>>> in community to do the necessary changes to upgrade > to a > > >>>>> newer > > >>>>>>>>>>>>>>>>>> version > > >>>>>>>>>>>>>>>>>> especially if those dependencies don't follow semver > > (has > > >>>>>>>>>>>>>>>>>> happened > > >>>>>>>>>>>>>>>>>> before > > >>>>>>>>>>>>>>>>>> as well, remember effort with ning). My caution comes > > from > > >>>>>>>>>>>>>>>>>> experiencing > > >>>>>>>>>>>>>>>>>> this situation before. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> I don't see how reporting helps. If a build succeeds, > I > > >>>> don't > > >>>>>>>>>>>>>>>>>> expect > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> anyone to look into the report, it is only when CI > build > > >>>>> fails, > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> committers > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> and reviewers look into the details. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> We can add a mandatory step during release that we > need > > >> to > > >>>>>>>>>>>>>>>>>>> assess > > >>>>>>>>>>>>>>>>>>> CVEs > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> matching this criteria before proceeding with the > > >> release. > > >>>>>>>>>>>>>>>>>>> This > > >>>>>>>>>>>>>>>>>>> could > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> end > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> up requiring upgrade of some dependencies and in other > > >>>> cases > > >>>>> it > > >>>>>>>>>>>>>>>>>> may > > >>>>>>>>>>>>>>>>>> not > > >>>>>>>>>>>>>>>>>> be > > >>>>>>>>>>>>>>>>>> needed. This assessment can also happen more often in > > >> adhoc > > >>>>>>>>>>>>>>>>>> fashion > > >>>>>>>>>>>>>>>>>> offline > > >>>>>>>>>>>>>>>>>> before release based upon interest from community. I > am > > >>>> also > > >>>>>>>>>>>>>>>>>> open > > >>>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>> making > > >>>>>>>>>>>>>>>>>> it mandatory with every PR, in future, like you are > > >>>>> suggesting, > > >>>>>>>>>>>>>>>>>> if > > >>>>>>>>>>>>>>>>>> we > > >>>>>>>>>>>>>>>>>> see > > >>>>>>>>>>>>>>>>>> sufficient uptake in community on these issues. From > > >>>>> experience > > >>>>>>>>>>>>>>>>>> this > > >>>>>>>>>>>>>>>>>> is > > >>>>>>>>>>>>>>>>>> not > > >>>>>>>>>>>>>>>>>> there currently and hence I don't want to do this now. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> IMO, it does not matter how CVE is introduced. It may > > be a > > >>>>> new > > >>>>>>>>>>>>>>>>>> dependency > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> with an existing CVE or it can be a new CVE for an > > >> existing > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> dependency. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> In > > >>>>>>>>>>>>>>>>>>> both cases, dependency with the CVE needs to be > fixed. > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> In one case the PR is not directly responsible for > the > > >>>> issue > > >>>>>>>>>>>>>>>>>>> and > > >>>>>>>>>>>>>>>>>>> hence > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> we > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> should avoid penalizing them or block them. > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Thank you, > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>> Vlad > > >>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> On 10/25/17 11:58, Pramod Immaneni wrote: > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> Thanks that sounds mostly fine except what happens if > > >>>> there > > >>>>>>>>>>>>>>>>>>> is a > > >>>>>>>>>>>>>>>>>>> cve > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> matching that severity in a dependency but it doesnt > > >>>> affect > > >>>>> us > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>> because > > >>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> let's say we don't exercise that part of > functionality > > >>>>> *and* > > >>>>>>>>>>>>>>>>>>>> there > > >>>>>>>>>>>>>>>>>>>> isn't a > > >>>>>>>>>>>>>>>>>>>> fix available or there is a fix but the upgrade > > requires > > >>>>>>>>>>>>>>>>>>>> significant > > >>>>>>>>>>>>>>>>>>>> effort > > >>>>>>>>>>>>>>>>>>>> (for example if we need to move to a new major > version > > >> of > > >>>>> the > > >>>>>>>>>>>>>>>>>>>> dependency > > >>>>>>>>>>>>>>>>>>>> or > > >>>>>>>>>>>>>>>>>>>> something like that). Is there a way to add an > > exception > > >>>>> like > > >>>>>>>>>>>>>>>>>>>> we > > >>>>>>>>>>>>>>>>>>>> did > > >>>>>>>>>>>>>>>>>>>> for > > >>>>>>>>>>>>>>>>>>>> checkstyle in the interim. How about reporting > instead > > >> of > > >>>>>>>>>>>>>>>>>>>> failing > > >>>>>>>>>>>>>>>>>>>> the > > >>>>>>>>>>>>>>>>>>>> builds. One of the steps in release process could be > > to > > >>>>>>>>>>>>>>>>>>>> investigate > > >>>>>>>>>>>>>>>>>>>> these > > >>>>>>>>>>>>>>>>>>>> reports before proceeding with the release. If a PR > > >>>>>>>>>>>>>>>>>>>> introduces > > >>>>>>>>>>>>>>>>>>>> new > > >>>>>>>>>>>>>>>>>>>> cves > > >>>>>>>>>>>>>>>>>>>> by > > >>>>>>>>>>>>>>>>>>>> virtue of adding a new dependency or changing an > > >> existing > > >>>>>>>>>>>>>>>>>>>> version, > > >>>>>>>>>>>>>>>>>>>> that > > >>>>>>>>>>>>>>>>>>>> would be of interest and can be subject to failure. > Is > > >>>>> there > > >>>>>>>>>>>>>>>>>>>> a > > >>>>>>>>>>>>>>>>>>>> way > > >>>>>>>>>>>>>>>>>>>> to > > >>>>>>>>>>>>>>>>>>>> distinguish that? > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> On Wed, Oct 25, 2017 at 8:52 AM Vlad Rozov < > > >>>>>>>>>>>>>>>>>>>> vro...@apache.org> > > >>>>>>>>>>>>>>>>>>>> wrote: > > >>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>> 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. > > >>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >> > > >> > > >
