I’ve not looked at the PRs but they sound useful. Keeping software secure these days is a moving target; we have to do work just to keep up. All of our dependencies are doing that work too, and so we need to keep up to date with them.
I think it would be useful to have a task before each release to merge in the ones that look important. If you are concerned that this will result in many “small” changes with no JIRA case number, the person merging the PRs could squash them into a single commit with its own JIRA case. (I’d use 'git cherry-pick … ; git cherry-pick ; git rebase -i origin/master’) Julian > On Oct 12, 2019, at 1:01 PM, Muhammad Gelbana <[email protected]> wrote: > > Why would we not merge those PRs or even disable the whole thing ? > > > > On Fri, Oct 11, 2019 at 12:09 AM Francis Chuang <[email protected]> > wrote: > >> Dependabot is a bot on Github that opens PRs to automatically upgrade >> out of date dependencies to fix security issues. Recently, Github >> acquired dependabot and is gradually enabling the bot on all repositories. >> >> It just opened a PR to upgrade a few dependencies in the Avatica >> repository: https://github.com/apache/calcite-avatica/pull/114 >> >> I'd like to start some discussion as to how we should deal with these >> PRs. For some background, dependency upgrades should usually have a jira >> issue number assigned, so that the change is fully trackable. We >> recently had some discussion regarding trivial fixes to documentation >> and the consensus was that changes to the code is not considered to be >> trivial and that an issue should be filed on jira. >> >> If we will not merge these PRs, I think it makes sense to ask infra to >> disable them. Having these open PRs and then closing them manually seem >> to generate a lot of noise. According to the documentation for >> dependabot [1] it appears that we can either opt out of having >> dependabot opening PRs completely or have it open PRs. There is no >> middle-ground where dependabot/Github sends members of the repo a >> notification for security issues, but do not open any PRs. >> >> What do you guys think? >> >> Francis >> >> [1] >> https://help.github.com/en/articles/configuring-automated-security-fixes >>
