How hard it is to vibe-code a script that finds the latest merged ancestor (LMA) commit for latest patchset of a Gerrit change? And that finds the Gerrit change of that LMA to see the date it was merged (because the git date is about commit author-creation, not merge)?
If those pre-requisities are ready, the auto-abandon script can be taught to auto-remove Verified+1 that have LMA now older than 7 (or 10) days, except when LMA is still the branch HEAD. And checkstyle job can also do the LMA age computation and give Verified-1 with a friendly Gerrit reply about rebasing. I hope abandon+reopen removes any previous Verified+1 already. The above is for verification reliability only, I do not have sharp enough opinions about reviewer queue size and auto-abandons. Vratko. From: [email protected] <[email protected]> On Behalf Of Stanislav Zaikin via lists.fd.io Sent: Thursday, 29 October, 2026 09:55 To: [email protected] Subject: Re: [vpp-dev] Improving VPP gerrit queue management & rebasing 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<http://lists.fd.io> <[email protected]<mailto:[email protected]>> wrote: Comments inline... On 10/28/26 04:16, Benoit Ganne (bganne) via lists.fd.io<http://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]<mailto:[email protected]> <[email protected]><mailto:[email protected]> on behalf of Florin Coras via lists.fd.io<http://lists.fd.io> <[email protected]><mailto:[email protected]> Sent: Wednesday, October 28, 2026 4:50 To: [email protected]<mailto:[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<http://lists.fd.io> <[email protected]><mailto:[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 (#27311): https://lists.fd.io/g/vpp-dev/message/27311 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]] -=-=-=-=-=-=-=-=-=-=-=-
