Hi everyone, Just to close off this thread, I just CTR’d a change based on the proposals given below.
https://github.com/apache/tinkerpop/commit/a6dc5b91219b68a7e5282f61fb4f752dea8646d7 Dependabot is now configured to ignore all minor and patch releases, and only open PRs for major upgrades targeting master. The frequency of dependabot has been reduced to monthly. I added a new section to the release docs for minor dependency updates to be considered prior to code freeze. I have also opened an INFRA ticket requesting dependabot security alerts be enabled: https://issues.apache.org/jira/browse/INFRA-26536. Thanks, Cole From: Stephen Mallette <spmalle...@gmail.com> Date: Wednesday, February 5, 2025 at 4:47 AM To: dev@tinkerpop.apache.org <dev@tinkerpop.apache.org> Subject: Re: [DISCUSS] Reconfiguration or Removal of Dependabot +1 to quieting dependabot. it mostly just creates neverending busywork. better to try to use it more strategically as you suggest. On Tue, Feb 4, 2025 at 6:45 PM Cole Greer <cole.gr...@improving.com.invalid> wrote: > 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 > Warning: The sender of this message could not be validated and may not be the actual sender.
