+1 to squashing all these changes during a release. However, my only
concern is that if upgrading the dependencies during a release breaks
something in the codebase and turns into a larger change. I think in
this case, the change should not be squashed with the other commits and
be a standalone one.
Francis
On 13/10/2019 4:16 pm, Julian Hyde wrote:
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 <mgelb...@apache.org> 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 <francischu...@apache.org>
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
