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 (#27303): https://lists.fd.io/g/vpp-dev/message/27303 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]] -=-=-=-=-=-=-=-=-=-=-=-
