I've been using Dependabot on my fork of a few Apache repos (including the Calcite related ones [1][2][3]) for over a year now. I had to configure dependabot to point to these repositories. It is a nice reminder of all the different dependencies that can be updated. There is also a nice link to the changelog/release notes typically so you can find out what changed. I didn't realize that Github was going to start pushing PRs.
Typically I've manually looked at the list of PRs and updated the dependencies accordingly after creating a Jira like CALCITE-2789 [4]. The PRs are a good sanity check if the change will be easy or not since the tests pass/fail based on the configured Travis jobs. After committing the change, I then go back to Github and either force dependabot to rebase the PRs or wait for dependabot to notice the update and it will autoclose the stale PRs. So I am in favor of using the automated PRs in some way at least to know what is out of date. I've seen some of the PRs do large jumps in dependency version (ie: 1.x to 2.x) so automerging probably isn't the best idea (unless there is a way to tag the PR as reviewed). I've been personally taking a monthly approach to dependencies for Apache Knox where I try to once a month update dependencies. This seems to me like a reasonable tradeoff of doing dependency updates frequently but not too frequently [5] and [6]. [1] https://github.com/risdenk/calcite/pulls [2] https://github.com/risdenk/calcite-avatica/pulls [3] https://github.com/risdenk/calcite-avatica-go/pulls [4] https://issues.apache.org/jira/browse/CALCITE-2789 [5] https://issues.apache.org/jira/browse/KNOX-2009 [6] https://issues.apache.org/jira/browse/KNOX-2049 Kevin Risden On Mon, Oct 14, 2019 at 6:40 AM Francis Chuang <[email protected]> wrote: > +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 <[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 > >>> > > >
