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