Hi everyone, I wanted to kick off a discussion around dependabot in our repo as I don’t think the current configuration is beneficial for us. As it currently stands, the repo is permanently cluttered by 30+ dependabot PRs. I tend to group the dependabots into 3 buckets: Trivial: (requires minimal work to evaluate and accept) Moderate: (requires follow-up investigations into potential conflicts, licensing concerns, or breaking changes) Blocked: (upgrade cannot proceed without conducting some major piece of work)
I think for each of these groups, we would be better served by some alternative process. Instead of the current flood of trivial dependabots, it would be more efficient to evaluate minor version bumps for dependencies roughly once per release cycle. This could either be done by adding this as another task for the release manager, or it could be approximated by reconfiguring dependabot to only run once per quarter for minor version bumps. Instead of having major version bumps (often involves breaking changes) targeting maintenance branches (eg 3.7-dev), they should at the very least be moved to only target master. I would argue that most of these pending major upgrades are better served as JIRAs than dependabot PRs as the actual upgrade requires substantial changes which aren’t covered by the dependabot. One example of the current process failing here (and what motivated this email) is Stephen’s recent PR upgrading to slf4j 2. We have had an open dependabot PR for this upgrade for over a year, which has been completely ignored until the upgrade was completed independently. It’s clear that dependabot isn’t adding any value for us in such cases. One final change I want to suggest is that we open a ticket with infra to see if we can enable dependabot security alerts in our repo. This could serve as a useful warning mechanism for security vulnerabilities which we are currently missing. I would be interested to gather feedback on where people think dependabots are and are not valuable, and if there are any additional suggestions to improve our processes or reduce clutter. Thanks, Cole
