following committer guideline when merging PR

Committers, Please make sure to follow Apex community guideline when merging PR http://apex.apache.org/contributing.html. 1. Ensure that basic requirements for a pull request are met. This includes: * Sufficient time has passed for others to review * PR was suffiently reviewed

Re: following committer guideline when merging PR

What's your concern with #669. It's a fix for a build issue (which you created) and was approved by two committers. Wasn't getting builds to successful state asap one of your top concerns based on your comments and -1 on #569 on core. On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov

[jira] [Resolved] (APEXMALHAR-2541) Fix travis-ci build

[ https://issues.apache.org/jira/browse/APEXMALHAR-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pramod Immaneni resolved APEXMALHAR-2541. - Resolution: Fixed Fix Version/s: 3.8.0 > Fix travis-ci build >

Re: following committer guideline when merging PR

item #3. The concern with #661 is with all items that I marked in red in my first email. Thank you, Vlad On 9/8/17 10:48, Pramod Immaneni wrote: What's your concern with #669. It's a fix for a build issue (which you created) and was approved by two committers. Wasn't getting builds to

Re: following committer guideline when merging PR

Regarding updating JIRA (item#3) I think it should ideally be the contributor's responsibility to update the JIRA with all the required fields and not the committer's. On Fri, Sep 8, 2017 at 11:25 AM, Vlad Rozov wrote: > item #3. The concern with #661 is with all items that

Re: following committer guideline when merging PR

Make sense. +1 Thks Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov wrote: > Committers, > > Please make sure to follow Apex community guideline when merging PR >

Re: following committer guideline when merging PR

Make sense. +1 Thks Amol E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre* www.datatorrent.com On Fri, Sep 8, 2017 at 9:16 AM, Vlad Rozov wrote: > Committers, > > Please make sure to follow Apex community guideline when merging PR >

Re: following committer guideline when merging PR

I'll repeat myself. Prior to suggesting new process, posting questions to dev@apex or voting, please take time to review existing documentation, discussion threads and the information posted on apex.apache.org. To answer your question regarding PR 669 - it is the committer responsibility to

Re: checking dependencies for known vulnerabilities

Manually during release is fine but we do need to come up with a process to shorten the cycle it will take to address these. Maybe we can come up with some guidelines on how to identify when something does not affect the software, for example, if a vulnerability comes into picture when a

Re: checking dependencies for known vulnerabilities

+1 that PR with newly introduced vulnerability should not be merged. Actually, my preference will be that such PR should not be even open. Thank you, Vlad On 9/8/17 15:44, Thomas Weise wrote: On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni wrote: Though I like the

Re: checking dependencies for known vulnerabilities

We will need to think about how much appetite the community has into looking into these issues if and once they are reported. Last time when a scan like this was run and several possible vulnerabilities in the dependencies were reported, it took about a year to verify and address them. Not because

Re: checking dependencies for known vulnerabilities

The proposal is to automate detecting CVEs in existing or newly added dependencies based on an externally supported and updated database. Currently, nobody from the community monitors new additions to known CVEs and whether or not they affect dependencies used by Apex. By using the proposed

Re: checking dependencies for known vulnerabilities

Vlad, Assuming you are in agreement that vulnerabilities should not be shown in public way; how would failing the build help. The reasons for failure will have be noted in public to be worked on. Anyway, IMO Apex may be better off exposing CVE as we are better off knowing these. But if folks want

Re: checking dependencies for known vulnerabilities

I believe the cost will be higher as it won't be like checkstyle where we establish a baseline because these are external dependencies and I am sure vulnerabilities are being reported all the time. I don't mind trying this out with release as the checkpoint where these issues need to be addressed

Re: checking dependencies for known vulnerabilities

My response inline On Fri, Sep 8, 2017 at 3:20 PM, Vlad Rozov wrote: > The proposal is to automate detecting CVEs in existing or newly added > dependencies based on an externally supported and updated database. > Currently, nobody from the community monitors new additions to

Re: checking dependencies for known vulnerabilities

On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni wrote: > Though I like the functionality of being able to detect if a new dependency > being added has vulnerabilities and prompting the search for a better > version, I am wary of tying a build strongly to vulnerability

Re: following committer guideline when merging PR

Sanjay, Please feel free to propose changes to the existing Apex contribution guidelines, but prior to doing that I'd strongly recommend all community members at least to review what already exists and to follow the guidelines [1]. Additionally, it will be good that the community members

Re: following committer guideline when merging PR

May be you can help clear the confusion for me. From the contribution guidelines you cited, it looks like it is already the contributor's responsibility to ensure all JIRA fields are correct and update them when the PR is merged. But in your original email you cited apex-malhar PR 669 as an

checking dependencies for known vulnerabilities

Any objections to implementing https://www.owasp.org/index.php/OWASP_Dependency_Check maven plugin that will run on Travis/Jenkins and check for known vulnerabilities? Thank you, Vlad

Re: checking dependencies for known vulnerabilities

+1 for implementing it. I'm not sure it will be suitable for CI build though due to initial download overhead? On Fri, Sep 8, 2017 at 1:33 PM, Vlad Rozov wrote: > Any objections to implementing https://www.owasp.org/index.ph > p/OWASP_Dependency_Check maven plugin that

Re: following committer guideline when merging PR

I cited both, in my first email I cited steps for a committer as it is a committer that verifies that a contribution meets a community guidelines. In reply back to Sanjay proposal, I cited part of the contribution guideline. IMO, it is not that the wording around JIRA or any other part of the

Re: following committer guideline when merging PR

Vlad cited committer not contributor guidelines, maybe that is the source of the confusion. If the wording in the contribution guidelines on the website for contributor responsibilities around JIRA is the cause for the ambiguity, let's fix it. Thanks On Fri, Sep 8, 2017 at 1:21 PM, Sanjay Pujare

Re: checking dependencies for known vulnerabilities

There are a couple of things here. You may be hard pressed to find software with no CVE vulnerabilities as security issues are found all the time so we should go with a guideline that is in the spirit of "let's discuss this addition and weigh the pros and cons" rather than "don't add whatsoever if

Re: checking dependencies for known vulnerabilities

Amol, Build may fail for multiple reasons, unless it outputs details of CVE that outlines how vulnerability can be exploited, the vulnerability is not exposed to the public. I am +1 that it is better to know and monitor vulnerabilities than to proceed with a risk of introducing new

Re: checking dependencies for known vulnerabilities

Can we build a way into CI to distinguish between these and a new vulnerability that has come up in an unchanged dependency? On Fri, Sep 8, 2017 at 3:44 PM, Thomas Weise wrote: > On Fri, Sep 8, 2017 at 3:36 PM, Pramod Immaneni > wrote: > > > Though I