Hi folks, I agree with Florin, rebase will waste a lot of CI. What about the following: 1) auto-abandon moved to 10 days of inactivity (maybe with a clear message about what it means: this is not a rejection, but a nudge for the author to rebase and chase maintainers - not sure what is says currently) 2) a patch that was verified more than 7 days ago looses its CI +1 with a clear message this needs a rebase to be verified again. Also acts as a nudge prior to auto-abandon (and the message may state that after 10 days of inactivity this is going to be abandon)
This should allow us to keep the queue manageable and also nudge authors and reviewers. Now, the bigger problem I think is that we are lacking active maintainers: my review queue keep growing although I try to review a few patches everyday. With auto-abandon we probably filter out some low-priority stuff (because if authors cannot be bothered to reopen/rebase it is a sign of low commitment) but still, it is hard to keep up in the AI era. Best ben ________________________________________ From: [email protected] <[email protected]> on behalf of Florin Coras via lists.fd.io <[email protected]> Sent: Wednesday, October 28, 2026 4:50 To: [email protected] Subject: Re: [vpp-dev] Improving VPP gerrit queue management & rebasing Hi Dave, Auto rebasing patches that have not been reviewed is going to waste a lot of our CI’s capacity. It makes sense to rebase patches only after review and if stale, where stale could be days, or weeks. If the queue is a concern, I do agree that we can auto-abandon patches after 10 days as they can be rebased/reopened later. Maintainers should be able to see patches assigned to them, so looking them up even if the queue is long shouldn’t be a problem. Regards, Florin On Oct 27, 2026, at 8:12 PM, Dave Wallace via lists.fd.io <[email protected]> wrote: Folks, There was a discussion at today's VPP Community meeting related to my previous email on rebasing gerrit changes weekly [0] and figuring out a better way to manage the VPP gerrit queue. Something needs to be done to help reduce the burden on code reviewers and reduce the time to get a gerrit change merged after passing CI verification. Having more folks review gerrit changes would help a lot, but would not reduce the friction with the current incoming rate of code submissions. The two main concerns under discussion are 1. Merging patches that have not been verified recently (within 7 days), is increases the risk of a test escape due to the lack of testing of a gerrit change on top of the latest merged changes. 2. The gerrit queue is so long (~ 250 presently) that scanning the gerrit queue is burdensome for reviewers The Envoy project handles this by requiring a submitter to actively engage with the reviewers after passing the test metrics. If an Envoy PR remains untouched by either a reviewer or submitter for 7 days, the PR is automatically closed. This does a good job with #2 but does not solve #1 because a PR that is reopened is not required to be rebased. Presently, there is daily github workflow [2] that both creates a vpp gerrit report and implements the 180 day auto-abandon process. Of major consequence to several solutions discussed, is the fact that gerrit 'resets the clock' when any attribute is changed. Thus, suggestions like auto-rebasing or clearing the Verified status will nullify the auto-abandon algorithm and allow the queue to grow without limits (as was the case prior to the implementation of the auto-abandon algorithm). My initial suggestion was to simply change the auto-abandon window from 180 days to 10 days, but like the envoy solution that does not solve issue #1. Perhaps the gerrit report script could detect and force a rebase for any gerrit change which was restored in conjunction with the reduction of the auto-abandon window to 10 days. However, any gerrit change which required manual merge conflict resolution could not be automatically rebased. The discussion was ended without coming to a conclusion, thus I am seeking input from the community as a whole. Please reply to this thread with your feedback and/or any alternative proposal to address the two issues under discussion. Thanks, -daw- [0] https://lists.fd.io/g/vpp-dev/topic/please_rebase_your_gerrit/121904738 [1] https://github.com/envoyproxy/envoy/blob/main/CONTRIBUTING.md#submitting-a-pr [2] https://github.com/vpp-dev/vpp-gerrit-report
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27306): https://lists.fd.io/g/vpp-dev/message/27306 Mute This Topic: https://lists.fd.io/mt/121971803/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
