My 2 cents as an occasional contributor: even in the pre-AI era most of (my) patches were awaiting for reviewer feedback for ~2-8 weeks, sometimes even more. So, in my opinion 10 days is a bit too short. Also, it looks like (at least for me) that some maintainers are not very active (if active at all; not judging here, just my observation).
This also will increase noise to maintainers: patch was abandoned, patch was re-opened, patch was rebased and so on. With that said, I'm more in favour of revoking CI's +1 (and maybe even enforcing that CI's +1 to be able to merge the patch). On Thu, 29 Oct 2026 at 04:20, Dave Wallace via lists.fd.io <dwallacelf= [email protected]> wrote: > Comments inline... > > On 10/28/26 04:16, Benoit Ganne (bganne) via lists.fd.io wrote: > > 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) > > Agreed. This is trivial to do along with a better message. The current > one message is > "Abandoned by https://github.com/vpp-dev/vpp-gerrit-report script due to > last-update-days >= 180" > > 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) > > Implementing this logic is not trivial and I presently don't have the > cycles to implement it. The code lives in > https://github.com/vpp-dev/vpp-gerrit-report if you want to take a shot > at it. > > 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. > > Indeed, this is a universal problem with OSS projects these days, but not > directly relevant to improving the signal-to-noise ratio in the gerrit > queue. > > Thanks, > -daw- > > 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]> <[email protected]> on > behalf of Florin Coras via lists.fd.io <[email protected]> > <[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]> <[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 > > > > > > > > > -- Best regards Stanislav Zaikin
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#27310): https://lists.fd.io/g/vpp-dev/message/27310 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]] -=-=-=-=-=-=-=-=-=-=-=-
