Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Ole Troan]

> Auto-abandon is not auto-delete.
> 
> Abandoned patches remain accessible in gerrit and the 600+ patches which 
> would be auto-abandoned would continue to exist in virtually the same state 
> as they do today.  Viewable by all and available to anyone interested in 
> utilizing them (i.e. restoring, rebasing, retesting).
> 
> In my experience, mentally processing auto-abandon is similar to getting used 
> to someone commenting with '-1' on a patch. It is not meant to be a rejection 
> of one's submission, but a means of communicating that someone has suggested 
> an improvement.
> 
> If an Auto-abandon notification is viewed as a reminder to rebase one's patch 
> and re-engage with the community committers, then it can be welcomed as a 
> positive part of the contribution process and not a negative rejection of 
> one's work.

I fully agree there are patches that should be abandoned in the queue. I also 
think notification about old patches in the queue is good.
I think we should consider different behaviour dependening on who's at "fault". 
Attached is a report against the open patches, matched against the maintainers 
file.
Trying to assign each patch to either "author", "maintainer" or "committer".

While I don't disagree with auto-abandoning per se. It hides the problem. And 
I'm not convinced we have consensus or understanding what the problem is.
What I perceived as one problem, was that patches don't get timely review (and 
therefore gets stuck in the queue for long).

The attached report uses the algorithm of:
 - if not verified, not mergeable or negative review or older than 30 days 
assign to author
 - else if not reviewed, assign to maintainers of all involved components
 - else if submittable and positively reviewed assign to commiters

Patches assigned:
 authors: 477
 maintainers: 42
  committers: 0

I don't think the 42 awaiting review should be auto-abandoned for example.
I was thinking of adding code reviewers from MAINTAINERS from the tool.

So my suggestion is something like:
1) Auto-add reviewers from MAINTAINERS and either via report/web-page whatever 
manage maintainers review load
2) Nag authors to refresh their patches, fix review comments via email. Use 
e.g. a 30 days grace period and then auto-abandon
   (might require tweaks to the auto-abandon plugin).

Doesn't seem like there is an issue actually getting patches merged when they 
are ready.

Cheers,
Ole

*** COMMITTERS ***
*** MAINTAINERS ***
policer: Neale Ranns 
31196: tests: add policer tests
   cause: missing review

unittest: Dave Barach ,Florin Coras ,Damjan Marion 
31130: ip: extend punt CLI for exception packets
   cause: missing review
30974: vlib: startup multi-arch variant configuration fix for interfaces
   cause: missing review
30998: tests: switch to GPL license
   cause: missing review
30654: vlib: nm_clone node_by_name re-assign to avoid coredump
   cause: missing review

ip6: Neale Ranns ,Jon Loeliger 
31130: ip: extend punt CLI for exception packets
   cause: missing review
30535: ip: Path MTU
   cause: missing review

ipsec: Neale Ranns ,Radu Nicolau 
31130: ip: extend punt CLI for exception packets
   cause: missing review

vxlan-gbp: Mohsin Kazmi ,Neale Ranns 
31130: ip: extend punt CLI for exception packets
   cause: missing review

build: Damjan Marion 
30384: misc: vpptop makefile target
   cause: missing review
30734: build: change default make verify os to ubuntu-20.04
   cause: missing review
31122: linux-cp: Linux Control Plane Netlink Listener
   cause: missing review

l2: John Lo ,Steven Luong 
31172: l2: crash on l2_input_is_xconnect
   cause: missing review

hsa: Florin Coras ,Dave Wallace ,Aloys 
Augustin ,Nathan Skrzypczak 
30036: tls: dtls initial implementation
   cause: missing review

tls: Florin Coras ,Ping Yu 
30036: tls: dtls initial implementation
   cause: missing review

vcl: Florin Coras 
30036: tls: dtls initial implementation
   cause: missing review
30998: tests: switch to GPL license
   cause: missing review
30792: build: add config option for LD_PRELOAD
   cause: missing review

session: Florin Coras 
30036: tls: dtls initial implementation
   cause: missing review

fib: Neale Ranns 
31166: fib: Always honour flow hash flag
   cause: missing review
30535: ip: Path MTU
   cause: missing review
30998: tests: switch to GPL license
   cause: missing review

wireguard: Artem Glazychev 
30695: wireguard: testing alternative timer dispatch
   cause: missing review
30998: tests: switch to GPL license
   cause: missing review

gre: Neale Ranns 
30535: ip: Path MTU
   cause: missing review
30998: tests: switch to GPL license
   cause: missing review

tests: Klement Sekera ,Paul Vinciguerra 

30535: ip: Path MTU
   cause: missing review
26291: tests: add tests for ip.api
   cause: missing review
30998: tests: switch to GPL license
   cause: missing review

dpdk: Damjan Marion 
30974: vlib: startup multi-arch variant configuration fix for interfaces
   cause: missing review
30996: dpd

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Damjan Marion via lists.fd.io]

Guys,

let’s use part of the next Tuesday community call ta talk about this and decide.

I will put it on the agenda….

— 
Damjan



> On 01.02.2021., at 16:17, Dave Wallace  wrote:
> 
> Ole,
> 
> Auto-abandon is not auto-delete.
> 
> Abandoned patches remain accessible in gerrit and the 600+ patches which 
> would be auto-abandoned would continue to exist in virtually the same state 
> as they do today.  Viewable by all and available to anyone interested in 
> utilizing them (i.e. restoring, rebasing, retesting).
> 
> In my experience, mentally processing auto-abandon is similar to getting used 
> to someone commenting with '-1' on a patch. It is not meant to be a rejection 
> of one's submission, but a means of communicating that someone has suggested 
> an improvement.
> 
> If an Auto-abandon notification is viewed as a reminder to rebase one's patch 
> and re-engage with the community committers, then it can be welcomed as a 
> positive part of the contribution process and not a negative rejection of 
> one's work.
> 
> Thanks,
> -daw-
> 
> 
> On 2/1/2021 9:38 AM, otr...@employees.org  wrote:
>> Dave,
>> 
>>> To be perfectly honest, other than Andrew's proposal to tweak the 
>>> auto-abandon parameters, I have not heard another solution that solves the 
>>> problem of cleaning up the current queue and limiting the size of the queue 
>>> in the future.  Is anyone going to volunteer to manually review/abandon 
>>> 600+ gerrit changes?  Auto-assigning maintainers to gerrit changes is a 
>>> separate issue. Please make a proposal to fix that in its own thread and I 
>>> will help to get that implemented.
>> What do you intend to happen with those 600+ abandonded changes in the 
>> future?
>> Assuming there is gold in quite a few of them.
>> 
>> Ole
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18672): https://lists.fd.io/g/vpp-dev/message/18672
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Dave Wallace]

Ole,

Auto-abandon is not auto-delete.

Abandoned patches remain accessible in gerrit and the 600+ patches which 
would be auto-abandoned would continue to exist in virtually the same 
state as they do today.  Viewable by all and available to anyone 
interested in utilizing them (i.e. restoring, rebasing, retesting).


In my experience, mentally processing auto-abandon is similar to getting 
used to someone commenting with '-1' on a patch. It is not meant to be a 
rejection of one's submission, but a means of communicating that someone 
has suggested an improvement.


If an Auto-abandon notification is viewed as a reminder to rebase one's 
patch and re-engage with the community committers, then it can be 
welcomed as a positive part of the contribution process and not a 
negative rejection of one's work.


Thanks,
-daw-


On 2/1/2021 9:38 AM, otr...@employees.org wrote:

Dave,


To be perfectly honest, other than Andrew's proposal to tweak the auto-abandon 
parameters, I have not heard another solution that solves the problem of 
cleaning up the current queue and limiting the size of the queue in the future. 
 Is anyone going to volunteer to manually review/abandon 600+ gerrit changes?  
Auto-assigning maintainers to gerrit changes is a separate issue. Please make a 
proposal to fix that in its own thread and I will help to get that implemented.

What do you intend to happen with those 600+ abandonded changes in the future?
Assuming there is gold in quite a few of them.

Ole



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18640): https://lists.fd.io/g/vpp-dev/message/18640
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Peter Mikus via lists.fd.io]

@Ole,

> What do you intend to happen with those 600+ abandonded changes in the future?

Clicking in gerrit on "restore" button, if you find a gold in there ;)


Peter Mikus
Engineer – Software
Cisco Systems Limited


From: vpp-dev@lists.fd.io  on behalf of Ole Troan 

Sent: Monday, February 1, 2021 15:38
To: Dave Wallace
Cc: Paul Vinciguerra; Andrew Yourtchenko; vpp-dev
Subject: Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

Dave,

> To be perfectly honest, other than Andrew's proposal to tweak the 
> auto-abandon parameters, I have not heard another solution that solves the 
> problem of cleaning up the current queue and limiting the size of the queue 
> in the future.  Is anyone going to volunteer to manually review/abandon 600+ 
> gerrit changes?  Auto-assigning maintainers to gerrit changes is a separate 
> issue. Please make a proposal to fix that in its own thread and I will help 
> to get that implemented.

What do you intend to happen with those 600+ abandonded changes in the future?
Assuming there is gold in quite a few of them.

Ole

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18639): https://lists.fd.io/g/vpp-dev/message/18639
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Ole Troan]

Dave,

> To be perfectly honest, other than Andrew's proposal to tweak the 
> auto-abandon parameters, I have not heard another solution that solves the 
> problem of cleaning up the current queue and limiting the size of the queue 
> in the future.  Is anyone going to volunteer to manually review/abandon 600+ 
> gerrit changes?  Auto-assigning maintainers to gerrit changes is a separate 
> issue. Please make a proposal to fix that in its own thread and I will help 
> to get that implemented.

What do you intend to happen with those 600+ abandonded changes in the future?
Assuming there is gold in quite a few of them.

Ole


signature.asc
Description: Message signed with OpenPGP

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18638): https://lists.fd.io/g/vpp-dev/message/18638
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Dave Wallace]

y setting
changeCleanup.abandonIfMergeable to false, it’s not perfect, of
course, but I think it will take care of most of the true “dead”
changes.

It seems like we already do have gerrit do the indexing, so it’s
no-cost operation.




While I agree with your idea that 'T' should be based on a time
other than the initial patch upload, I don't see a mechanism to
do so.  It would appear to me that the only other solution would
be to make the window larger and anything up to the release cycle
duration (120 days) seems reasonable to me.

The other point I would make is that auto-abandon is not
deletion.  Thus it puts more ownership on the patch creator to
poke the maintainer(s) for a review. And I'm assuming that
'Restore' resets the clock on the auto-abandon trigger.


True, and we could put the appropriate abandon message that would
describes what to do and explains why, so people don’t get
upset/annoyed.




Lastly, I have not heard a counter-proposal from either you or
Ole on how to clean up the current state of the queue.  We're
wasting cycles and abusing the infra by letting the queue remain
so large and it would be wise to address that sooner rather than
later.


If we decide to enable it, shout loudly on the list and give folks
a month warning before actually enable it, to touch the changes
they intend on working on. Then enable the plugin. Then start with
whatever nagging/reporting process from clean slate on top of the
plugin being already active.

To be clear: I think that there are two separate things:

1)  having a boatload of super outdated open changes
2) avoiding such changes piling up in the future/improving the
review time

The enabling of the plugin proposal solves (1), which is an
immediate technical problem.

Ole’s proposal seems to me to be aimed to address the (1) via (2),
so my comment was that I disagreed that the suggested approach of
addressing (2) is going to work, thus the suggested tweak.

I still think it’s fine to enable the plugin (with not deleting
the mergeable changes config), and it will solve the (1), and then
discuss how to tackle (2).

—a



Thanks,
-daw-

On 1/28/2021 4:29 AM, Andrew 👽 Yourtchenko wrote:

On 28 Jan 2021, at 10:10, Ole Troan  
<mailto:otr...@employees.org>  wrote:

My impression is that there is a disconnect between someone putting 
something on gerrit and a vpp maintainer reviewing and contributor merging.

Absolutely agree on that.

As a project we certainly can do better on managing the stream of changes. 
With my release manager hat on, I have seen a non-trivial number of cases where 
the patch sits for a while, then “oh damn it’s release time”, it gets squeezed 
in last moment, with predictable consequences.


I was thinking of having a script processing the review queue and 
generating reports for each maintainer. Then give each author a chance to get 
their code reviewed and merged.

if the maintainers don’t look at the new changes today, why would they look 
at the reports on the changes they didn’t look at ?


I would like to try the gentle nudge first. If we go down the abandon 
route, certainly not without sending alerts first.

If a person is legit swamped, the robotic nags will just annoy them and 
will go into recycle bin. I kinda like the idea of nudges but to have a chance 
to help - they need to go to the mail list where the other people might jump 
in... (of course the code owners have the final say but often there can be 
basic things that can be done. Maybe even do it over the email altogether - 
there was a recent experience on the list and I think it might not be a bad 
idea to make it a more frequent occurrence...

Then a possible sequence could be:

T: author submits the patch without their own “-1/-2” or removed -1/-2
T+7: the mail to vpp-dev is sent
T+30: autoabandon plugin triggers if no activity on the patch


—a



So a tentative -1.

Cheers
Ole




On 28 Jan 2021, at 09:19, Benoit Ganne (bganne) vialists.fd.io  <http://lists.fd.io>  
  <mailto:bganne=cisco@lists.fd.io>  wrote:

+1

ben


-Original Message-
From:vpp-dev@lists.fd.io  <mailto:vpp-dev@lists.fd.io>
<mailto:vpp-dev@lists.fd.io>  On Behalf Of Dave Wallace
Sent: mercredi 27 janvier 2021 22:50
To:vpp-dev@lists.fd.io  <mailto:vpp-dev@lists.fd.io>
Subject: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

Folks,

There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
being submitted on Jun 13, 2016 [1]!

I would like to propose that the Gerrit Review Auto-Abandon job [2] to
reduce the size of the queue to a more reasonable length. Benefits include
(from 

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Paul Vinciguerra]

Ben,

It was not intended toward you at all.  In fact, in my experience, you are
very helpful.  I was only looking to highlight cases that did not
specifically benefit me.

Would you like a different change for me to highlight?  How about
https://gerrit.fd.io/r/c/vpp/+/27349? That is mine, though.

Let me share with the list, another illustrative example of the actual
point I'm trying to make. I reached out to Florin and Ben about an ASAN
crash in the debug CI job.  I am the first to admit that I know nothing
about ASAN.  Ben promptly submitted a fix, but Florin said he was in the
process of a significant refactor and asked if it could be held back until
after then.

This is yet another reason why we should not auto-delete submissions.
Period.  Most of you have a VPP dev environment setup already, so tossing
in a changeset is no big thing.  But when folks go to the wiki, follow the
steps for all the hoops that they have to jump through to get a change
submitted, and for a change to be ignored is just wrong.  If someone cares
enough about the project to go through the effort, they deserve feedback.

A while back, Ole asked on the list, if he should set up a wiki page.  I
said I was against it, because anyone can edit a wiki page.  He, however,
is one of a very small group who can actually clear the backlog.  If we
truly want to grow the community, we have to act in ways that welcome folks
to the community.  Ignoring contributions and auto-deleting them is not
welcoming in my opinion.

If one thinks that auto-delete is a valid option, then auto-submit must be
equally valid.  Both address a MAINTAINERS lack of attention.  In an
auto-delete scenario, the maintainer is rewarded for ignoring the
changeset, is an auto-submit, he is not.

To your point, I agree with you.  I don't want to touch other MAINTAINERs
areas either, that's why I've been just leaving +1's, as I said in my
original post, as my practice lately.

Dave,
Let me know how I can help.





On Fri, Jan 29, 2021 at 9:51 AM Benoit Ganne (bganne) 
wrote:

> Hi Paul,
>
> as you refer to this specific story which is close to my heart (as I am
> the one who triggered the whole drama by -2'ed), let me clarify:
>
> > The Netgate folks had a changeset they were waiting a month or so for a
> > review, then they were told that it was too close to the release to merge
> > it.  It was merged, but the argument that "because we held you back,
> we're
> > going to hold you back some more" is very anti-community.
>
> I am not disagreeing we have an issue with the merging process, but this
> is not what happened for this specific change (see below).
> I apologized to Jon (patch author) and from the discussion I had with him
> we both agreed we were acting in good faith.
> Anyway, the net result of all this is I am now reluctant to review
> anything for which I am not a maintainer (so less review manpower).
>
> Here is the story from my point-of-view:
>  * I did a patch that I abandoned on Jon's request (because Jon's and my
> were trying to fix the same problem but Jon's was more complete) and then
> did initial reviews on Jon's patch when he pushed it: I was looking forward
> for it to be merged and spent time on it
>  * then I saw a number of updates by Jon (-2, -1, new patches) between
> patchset 2 on Nov 30 until the last significant change with Patchset 5 on
> Dec 7
> => I did not spent time to review waiting for the final version, because I
> understood Jon were still actively debugging/updating it. Reviews take
> time, so I'd rather review when it is considered as "done" by the author
>  * it is only when Jon pinged again that I looked at it again and asked
> Andrew and Dave, respectively because of their release manager hat and
> maintainer hat
>
> I am not saying it was the best way of managing it, and this is definitely
> not how it was received/understood. I understand that. But there was no
> nefarious anti-community intent.
>
> Best
> ben
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18630): https://lists.fd.io/g/vpp-dev/message/18630
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Benoit Ganne (bganne) via lists.fd.io]

Hi Paul,

as you refer to this specific story which is close to my heart (as I am the one 
who triggered the whole drama by -2'ed), let me clarify:

> The Netgate folks had a changeset they were waiting a month or so for a
> review, then they were told that it was too close to the release to merge
> it.  It was merged, but the argument that "because we held you back, we're
> going to hold you back some more" is very anti-community.

I am not disagreeing we have an issue with the merging process, but this is not 
what happened for this specific change (see below).
I apologized to Jon (patch author) and from the discussion I had with him we 
both agreed we were acting in good faith.
Anyway, the net result of all this is I am now reluctant to review anything for 
which I am not a maintainer (so less review manpower).

Here is the story from my point-of-view:
 * I did a patch that I abandoned on Jon's request (because Jon's and my were 
trying to fix the same problem but Jon's was more complete) and then did 
initial reviews on Jon's patch when he pushed it: I was looking forward for it 
to be merged and spent time on it
 * then I saw a number of updates by Jon (-2, -1, new patches) between patchset 
2 on Nov 30 until the last significant change with Patchset 5 on Dec 7
=> I did not spent time to review waiting for the final version, because I 
understood Jon were still actively debugging/updating it. Reviews take time, so 
I'd rather review when it is considered as "done" by the author
 * it is only when Jon pinged again that I looked at it again and asked Andrew 
and Dave, respectively because of their release manager hat and maintainer hat

I am not saying it was the best way of managing it, and this is definitely not 
how it was received/understood. I understand that. But there was no nefarious 
anti-community intent.

Best
ben

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18629): https://lists.fd.io/g/vpp-dev/message/18629
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Paul Vinciguerra]

n is that there is a disconnect between someone putting 
> something on gerrit and a vpp maintainer reviewing and contributor merging.
>
> Absolutely agree on that.
>
> As a project we certainly can do better on managing the stream of changes. 
> With my release manager hat on, I have seen a non-trivial number of cases 
> where the patch sits for a while, then “oh damn it’s release time”, it gets 
> squeezed in last moment, with predictable consequences.
>
>
> I was thinking of having a script processing the review queue and generating 
> reports for each maintainer. Then give each author a chance to get their code 
> reviewed and merged.
>
> if the maintainers don’t look at the new changes today, why would they look 
> at the reports on the changes they didn’t look at ?
>
>
> I would like to try the gentle nudge first. If we go down the abandon route, 
> certainly not without sending alerts first.
>
> If a person is legit swamped, the robotic nags will just annoy them and will 
> go into recycle bin. I kinda like the idea of nudges but to have a chance to 
> help - they need to go to the mail list where the other people might jump 
> in... (of course the code owners have the final say but often there can be 
> basic things that can be done. Maybe even do it over the email altogether - 
> there was a recent experience on the list and I think it might not be a bad 
> idea to make it a more frequent occurrence...
>
> Then a possible sequence could be:
>
> T: author submits the patch without their own “-1/-2” or removed -1/-2
> T+7: the mail to vpp-dev is sent
> T+30: autoabandon plugin triggers if no activity on the patch
>
>
> —a
>
>
>
> So a tentative -1.
>
> Cheers
> Ole
>
>
>
>
> On 28 Jan 2021, at 09:19, Benoit Ganne (bganne) via lists.fd.io 
>   wrote:
>
> +1
>
> ben
>
>
> -Original Message-
> From: vpp-dev@lists.fd.io   On 
> Behalf Of Dave Wallace
> Sent: mercredi 27 janvier 2021 22:50
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
>
> Folks,
>
> There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
> being submitted on Jun 13, 2016 [1]!
>
> I would like to propose that the Gerrit Review Auto-Abandon job [2] to
> reduce the size of the queue to a more reasonable length. Benefits include
> (from [3]):
>
> - %< -
>
> Abandoning old inactive changes has the following advantages:
>
>   it signals change authors that changes are considered outdated
>
>   it keeps dashboards clean
>
>   it reduces the load on the server (for open changes the mergeability
> flag is recomputed whenever a change is merged)
>
> If a change is still wanted it can be restored by clicking on the Restore
> button.
>
> - %< -
>
> I would like to propose the following configuration [2] for auto-abandon:
>
> changeCleanup.abandonAfter: 30d
> changeCleanup.abandonIfMergeable:   default (true)
> changeCleanup.cleanupAccountPatchReview:default (false)
> changeCleanup.abandonMessage:   default
> changeCleanup.startTime:Sat 00:00
> changeCleanup.interval: 1 day
>
> If you are opposed to the use of Auto-abandon, please propose an
> alternative method to clean up the backlog of reviews on VPP master and
> maintain a reasonably sized queue.
> If you approve of the concept, please respond with a +1.
> If you approve of the concept but don't like the configuration, please
> respond with your preferred configuration.
>
> Lack of response will be interpreted as approval of the use of auto-
> abandon with the proposed configuration ;)
>
> Thanks,
> -daw-
>
> [0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
> status:open project:vpp branch:master --format=JSON --no-limit | tail -1
> {"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":fa
> lse}
> [1] https://gerrit.fd.io/r/c/vpp/+/1529
> [2] https://gerrit-review.googlesource.com/Documentation/config-
> gerrit.html#changeCleanup
> [3] https://gerrit-review.googlesource.com/Documentation/user-change-
> cleanup.html#auto-abandon
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18627): https://lists.fd.io/g/vpp-dev/message/18627
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Andrew Yourtchenko]

Dave,

> On 28 Jan 2021, at 16:59, Dave Wallace  wrote:
> 
>  Andrew,
> 
> The only issue I have with your proposal is that there is no way to implement 
> it. Gerrit auto-abandon doesn't have a way to detect 'T'.

We could approximate it by setting changeCleanup.abandonIfMergeable to false, 
it’s not perfect, of course, but I think it will take care of most of the true 
“dead” changes.

It seems like we already do have gerrit do the indexing, so it’s no-cost 
operation.


> 
> While I agree with your idea that 'T' should be based on a time other than 
> the initial patch upload, I don't see a mechanism to do so.  It would appear 
> to me that the only other solution would be to make the window larger and 
> anything up to the release cycle duration (120 days) seems reasonable to me.
> 
> The other point I would make is that auto-abandon is not deletion.  Thus it 
> puts more ownership on the patch creator to poke the maintainer(s) for a 
> review.  And I'm assuming that 'Restore' resets the clock on the auto-abandon 
> trigger.

True, and we could put the appropriate abandon message that would describes 
what to do and explains why, so people don’t get upset/annoyed.


> 
> Lastly, I have not heard a counter-proposal from either you or Ole on how to 
> clean up the current state of the queue.  We're wasting cycles and abusing 
> the infra by letting the queue remain so large and it would be wise to 
> address that sooner rather than later.

If we decide to enable it, shout loudly on the list and give folks a month 
warning before actually enable it, to touch the changes they intend on working 
on. Then enable the plugin. Then start with whatever nagging/reporting process 
from clean slate on top of the plugin being already active.

To be clear: I think that there are two separate things:

1)  having a boatload of super outdated open changes 
2) avoiding such changes piling up in the future/improving the review time

The enabling of the plugin proposal solves (1), which is an immediate technical 
problem.

Ole’s proposal seems to me to be aimed to address the (1) via (2), so my 
comment was that I disagreed that the suggested approach of addressing (2) is 
going to work, thus the suggested tweak.

I still think it’s fine to enable the plugin (with not deleting the mergeable 
changes config), and it will solve the (1), and then discuss how to tackle (2).

—a


> Thanks,
> -daw-
> 
> On 1/28/2021 4:29 AM, Andrew 👽 Yourtchenko wrote:
>>>> On 28 Jan 2021, at 10:10, Ole Troan  wrote:
>>>> 
>>>> My impression is that there is a disconnect between someone putting 
>>>> something on gerrit and a vpp maintainer reviewing and contributor merging.
>>> Absolutely agree on that.
>>> 
>>> As a project we certainly can do better on managing the stream of changes. 
>>> With my release manager hat on, I have seen a non-trivial number of cases 
>>> where the patch sits for a while, then “oh damn it’s release time”, it gets 
>>> squeezed in last moment, with predictable consequences.
>>> 
>>> I was thinking of having a script processing the review queue and 
>>> generating reports for each maintainer. Then give each author a chance to 
>>> get their code reviewed and merged. 
>> if the maintainers don’t look at the new changes today, why would they look 
>> at the reports on the changes they didn’t look at ?
>> 
>>> I would like to try the gentle nudge first. If we go down the abandon 
>>> route, certainly not without sending alerts first. 
>> If a person is legit swamped, the robotic nags will just annoy them and will 
>> go into recycle bin. I kinda like the idea of nudges but to have a chance to 
>> help - they need to go to the mail list where the other people might jump 
>> in... (of course the code owners have the final say but often there can be 
>> basic things that can be done. Maybe even do it over the email altogether - 
>> there was a recent experience on the list and I think it might not be a bad 
>> idea to make it a more frequent occurrence...
>> 
>> Then a possible sequence could be:
>> 
>> T: author submits the patch without their own “-1/-2” or removed -1/-2
>> T+7: the mail to vpp-dev is sent 
>> T+30: autoabandon plugin triggers if no activity on the patch 
>> 
>> 
>> —a
>> 
>> 
>>> So a tentative -1.
>>> 
>>> Cheers 
>>> Ole
>>> 
>>> 
>>> 
>>>>> On 28 Jan 2021, at 09:19, Benoit Ganne (bganne) via lists.fd.io 
>>>>>  wrote:
>>>>> 
>>>>> +1
>>>>> 
>>&g

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Ole Troan]

> On 28 Jan 2021, at 16:59, Dave Wallace  wrote:
> 
> Lastly, I have not heard a counter-proposal from either you or Ole on how to 
> clean up the current state of the queue. 

Write a tool that assigns reviews to maintainers. Generate reports and send 
nag-o-grams.

Then if that doesn’t work. Look at auto abandon. But it should be with warning 
notifications. And timer reset foreach change to patch. 

Cheers 
Ole



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18620): https://lists.fd.io/g/vpp-dev/message/18620
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Dave Wallace]

Andrew,

The only issue I have with your proposal is that there is no way to 
implement it. Gerrit auto-abandon doesn't have a way to detect 'T'.


While I agree with your idea that 'T' should be based on a time other 
than the initial patch upload, I don't see a mechanism to do so.  It 
would appear to me that the only other solution would be to make the 
window larger and anything up to the release cycle duration (120 days) 
seems reasonable to me.


The other point I would make is that auto-abandon is not deletion.  Thus 
it puts more ownership on the patch creator to poke the maintainer(s) 
for a review.  And I'm assuming that 'Restore' resets the clock on the 
auto-abandon trigger.


Lastly, I have not heard a counter-proposal from either you or Ole on 
how to clean up the current state of the queue.  We're wasting cycles 
and abusing the infra by letting the queue remain so large and it would 
be wise to address that sooner rather than later.


Thanks,
-daw-

On 1/28/2021 4:29 AM, Andrew 👽 Yourtchenko wrote:

On 28 Jan 2021, at 10:10, Ole Troan  wrote:

My impression is that there is a disconnect between someone putting something 
on gerrit and a vpp maintainer reviewing and contributor merging.

Absolutely agree on that.

As a project we certainly can do better on managing the stream of changes. With 
my release manager hat on, I have seen a non-trivial number of cases where the 
patch sits for a while, then “oh damn it’s release time”, it gets squeezed in 
last moment, with predictable consequences.


I was thinking of having a script processing the review queue and generating 
reports for each maintainer. Then give each author a chance to get their code 
reviewed and merged.

if the maintainers don’t look at the new changes today, why would they look at 
the reports on the changes they didn’t look at ?


I would like to try the gentle nudge first. If we go down the abandon route, 
certainly not without sending alerts first.

If a person is legit swamped, the robotic nags will just annoy them and will go 
into recycle bin. I kinda like the idea of nudges but to have a chance to help 
- they need to go to the mail list where the other people might jump in... (of 
course the code owners have the final say but often there can be basic things 
that can be done. Maybe even do it over the email altogether - there was a 
recent experience on the list and I think it might not be a bad idea to make it 
a more frequent occurrence...

Then a possible sequence could be:

T: author submits the patch without their own “-1/-2” or removed -1/-2
T+7: the mail to vpp-dev is sent
T+30: autoabandon plugin triggers if no activity on the patch


—a



So a tentative -1.

Cheers
Ole




On 28 Jan 2021, at 09:19, Benoit Ganne (bganne) via lists.fd.io 
 wrote:

+1

ben


-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
Sent: mercredi 27 janvier 2021 22:50
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

Folks,

There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
being submitted on Jun 13, 2016 [1]!

I would like to propose that the Gerrit Review Auto-Abandon job [2] to
reduce the size of the queue to a more reasonable length. Benefits include
(from [3]):

- %< -

Abandoning old inactive changes has the following advantages:

   it signals change authors that changes are considered outdated

   it keeps dashboards clean

   it reduces the load on the server (for open changes the mergeability
flag is recomputed whenever a change is merged)

If a change is still wanted it can be restored by clicking on the Restore
button.

- %< -

I would like to propose the following configuration [2] for auto-abandon:

changeCleanup.abandonAfter: 30d
changeCleanup.abandonIfMergeable:   default (true)
changeCleanup.cleanupAccountPatchReview:default (false)
changeCleanup.abandonMessage:   default
changeCleanup.startTime:Sat 00:00
changeCleanup.interval: 1 day

If you are opposed to the use of Auto-abandon, please propose an
alternative method to clean up the backlog of reviews on VPP master and
maintain a reasonably sized queue.
If you approve of the concept, please respond with a +1.
If you approve of the concept but don't like the configuration, please
respond with your preferred configuration.

Lack of response will be interpreted as approval of the use of auto-
abandon with the proposed configuration ;)

Thanks,
-daw-

[0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
status:open project:vpp branch:master --format=JSON --no-limit | tail -1
{"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":fa
lse}
[1] https://gerrit.fd.io/r/c/vpp/+/1529
[2] https://gerrit-review.googlesource.com/Docum

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Andrew Yourtchenko]

> On 28 Jan 2021, at 10:10, Ole Troan  wrote:
> 
> My impression is that there is a disconnect between someone putting 
> something on gerrit and a vpp maintainer reviewing and contributor merging.

Absolutely agree on that.

As a project we certainly can do better on managing the stream of changes. With 
my release manager hat on, I have seen a non-trivial number of cases where the 
patch sits for a while, then “oh damn it’s release time”, it gets squeezed in 
last moment, with predictable consequences.

> 
> I was thinking of having a script processing the review queue and generating 
> reports for each maintainer. Then give each author a chance to get their code 
> reviewed and merged. 

if the maintainers don’t look at the new changes today, why would they look at 
the reports on the changes they didn’t look at ?

> 
> I would like to try the gentle nudge first. If we go down the abandon route, 
> certainly not without sending alerts first. 

If a person is legit swamped, the robotic nags will just annoy them and will go 
into recycle bin. I kinda like the idea of nudges but to have a chance to help 
- they need to go to the mail list where the other people might jump in... (of 
course the code owners have the final say but often there can be basic things 
that can be done. Maybe even do it over the email altogether - there was a 
recent experience on the list and I think it might not be a bad idea to make it 
a more frequent occurrence...

Then a possible sequence could be:

T: author submits the patch without their own “-1/-2” or removed -1/-2
T+7: the mail to vpp-dev is sent 
T+30: autoabandon plugin triggers if no activity on the patch 


—a


> 
> So a tentative -1.
> 
> Cheers 
> Ole
> 
> 
> 
>> On 28 Jan 2021, at 09:19, Benoit Ganne (bganne) via lists.fd.io 
>>  wrote:
>> 
>> +1
>> 
>> ben
>> 
>>> -Original Message-
>>> From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
>>> Sent: mercredi 27 janvier 2021 22:50
>>> To: vpp-dev@lists.fd.io
>>> Subject: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
>>> 
>>> Folks,
>>> 
>>> There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
>>> being submitted on Jun 13, 2016 [1]!
>>> 
>>> I would like to propose that the Gerrit Review Auto-Abandon job [2] to
>>> reduce the size of the queue to a more reasonable length. Benefits include
>>> (from [3]):
>>> 
>>> - %< -
>>> 
>>> Abandoning old inactive changes has the following advantages:
>>> 
>>>   it signals change authors that changes are considered outdated
>>> 
>>>   it keeps dashboards clean
>>> 
>>>   it reduces the load on the server (for open changes the mergeability
>>> flag is recomputed whenever a change is merged)
>>> 
>>> If a change is still wanted it can be restored by clicking on the Restore
>>> button.
>>> 
>>> - %< -
>>> 
>>> I would like to propose the following configuration [2] for auto-abandon:
>>> 
>>> changeCleanup.abandonAfter: 30d
>>> changeCleanup.abandonIfMergeable:   default (true)
>>> changeCleanup.cleanupAccountPatchReview:default (false)
>>> changeCleanup.abandonMessage:   default
>>> changeCleanup.startTime:Sat 00:00
>>> changeCleanup.interval: 1 day
>>> 
>>> If you are opposed to the use of Auto-abandon, please propose an
>>> alternative method to clean up the backlog of reviews on VPP master and
>>> maintain a reasonably sized queue.
>>> If you approve of the concept, please respond with a +1.
>>> If you approve of the concept but don't like the configuration, please
>>> respond with your preferred configuration.
>>> 
>>> Lack of response will be interpreted as approval of the use of auto-
>>> abandon with the proposed configuration ;)
>>> 
>>> Thanks,
>>> -daw-
>>> 
>>> [0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
>>> status:open project:vpp branch:master --format=JSON --no-limit | tail -1
>>> {"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":fa
>>> lse}
>>> [1] https://gerrit.fd.io/r/c/vpp/+/1529
>>> [2] https://gerrit-review.googlesource.com/Documentation/config-
>>> gerrit.html#changeCleanup
>>> [3] https://gerrit-review.googlesource.com/Documentation/user-change-
>>> cleanup.html#auto-abandon
>> 
>> 
>> 
>> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18616): https://lists.fd.io/g/vpp-dev/message/18616
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Ole Troan]

My impression is that there is a disconnect between someone putting something 
on gerrit and a vpp maintainer reviewing and contributor merging.

I was thinking of having a script processing the review queue and generating 
reports for each maintainer. Then give each author a chance to get their code 
reviewed and merged. 

I would like to try the gentle nudge first. If we go down the abandon route, 
certainly not without sending alerts first. 

So a tentative -1.

Cheers 
Ole



> On 28 Jan 2021, at 09:19, Benoit Ganne (bganne) via lists.fd.io 
>  wrote:
> 
> +1
> 
> ben
> 
>> -Original Message-
>> From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
>> Sent: mercredi 27 janvier 2021 22:50
>> To: vpp-dev@lists.fd.io
>> Subject: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
>> 
>> Folks,
>> 
>> There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
>> being submitted on Jun 13, 2016 [1]!
>> 
>> I would like to propose that the Gerrit Review Auto-Abandon job [2] to
>> reduce the size of the queue to a more reasonable length. Benefits include
>> (from [3]):
>> 
>> - %< -
>> 
>> Abandoning old inactive changes has the following advantages:
>> 
>>it signals change authors that changes are considered outdated
>> 
>>it keeps dashboards clean
>> 
>>it reduces the load on the server (for open changes the mergeability
>> flag is recomputed whenever a change is merged)
>> 
>> If a change is still wanted it can be restored by clicking on the Restore
>> button.
>> 
>> - %< -
>> 
>> I would like to propose the following configuration [2] for auto-abandon:
>> 
>> changeCleanup.abandonAfter: 30d
>> changeCleanup.abandonIfMergeable:   default (true)
>> changeCleanup.cleanupAccountPatchReview:default (false)
>> changeCleanup.abandonMessage:   default
>> changeCleanup.startTime:Sat 00:00
>> changeCleanup.interval: 1 day
>> 
>> If you are opposed to the use of Auto-abandon, please propose an
>> alternative method to clean up the backlog of reviews on VPP master and
>> maintain a reasonably sized queue.
>> If you approve of the concept, please respond with a +1.
>> If you approve of the concept but don't like the configuration, please
>> respond with your preferred configuration.
>> 
>> Lack of response will be interpreted as approval of the use of auto-
>> abandon with the proposed configuration ;)
>> 
>> Thanks,
>> -daw-
>> 
>> [0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
>> status:open project:vpp branch:master --format=JSON --no-limit | tail -1
>> {"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":fa
>> lse}
>> [1] https://gerrit.fd.io/r/c/vpp/+/1529
>> [2] https://gerrit-review.googlesource.com/Documentation/config-
>> gerrit.html#changeCleanup
>> [3] https://gerrit-review.googlesource.com/Documentation/user-change-
>> cleanup.html#auto-abandon
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18615): https://lists.fd.io/g/vpp-dev/message/18615
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Benoit Ganne (bganne) via lists.fd.io]

+1

ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
> Sent: mercredi 27 janvier 2021 22:50
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master
> 
> Folks,
> 
> There are currently 636 open Gerrit Reviews on VPP master [0], the oldest
> being submitted on Jun 13, 2016 [1]!
> 
> I would like to propose that the Gerrit Review Auto-Abandon job [2] to
> reduce the size of the queue to a more reasonable length. Benefits include
> (from [3]):
> 
> - %< -
> 
> Abandoning old inactive changes has the following advantages:
> 
> it signals change authors that changes are considered outdated
> 
> it keeps dashboards clean
> 
> it reduces the load on the server (for open changes the mergeability
> flag is recomputed whenever a change is merged)
> 
> If a change is still wanted it can be restored by clicking on the Restore
> button.
> 
> - %< -
> 
> I would like to propose the following configuration [2] for auto-abandon:
> 
> changeCleanup.abandonAfter: 30d
> changeCleanup.abandonIfMergeable:   default (true)
> changeCleanup.cleanupAccountPatchReview:default (false)
> changeCleanup.abandonMessage:   default
> changeCleanup.startTime:Sat 00:00
> changeCleanup.interval: 1 day
> 
> If you are opposed to the use of Auto-abandon, please propose an
> alternative method to clean up the backlog of reviews on VPP master and
> maintain a reasonably sized queue.
> If you approve of the concept, please respond with a +1.
> If you approve of the concept but don't like the configuration, please
> respond with your preferred configuration.
> 
> Lack of response will be interpreted as approval of the use of auto-
> abandon with the proposed configuration ;)
> 
> Thanks,
> -daw-
> 
> [0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query
> status:open project:vpp branch:master --format=JSON --no-limit | tail -1
> {"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":fa
> lse}
> [1] https://gerrit.fd.io/r/c/vpp/+/1529
> [2] https://gerrit-review.googlesource.com/Documentation/config-
> gerrit.html#changeCleanup
> [3] https://gerrit-review.googlesource.com/Documentation/user-change-
> cleanup.html#auto-abandon


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18614): https://lists.fd.io/g/vpp-dev/message/18614
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Damjan Marion via lists.fd.io]

+1

— 
Damjan

> 
> On 27.01.2021., at 22:49, Dave Wallace  wrote:
> 
>  Folks,
> 
> There are currently 636 open Gerrit Reviews on VPP master [0], the oldest 
> being submitted on Jun 13, 2016 [1]!
> 
> I would like to propose that the Gerrit Review Auto-Abandon job [2] to reduce 
> the size of the queue to a more reasonable length. Benefits include (from 
> [3]):
> 
> - %< -
> Abandoning old inactive changes has the following advantages:
> 
> it signals change authors that changes are considered outdated
> 
> it keeps dashboards clean
> 
> it reduces the load on the server (for open changes the mergeability flag 
> is recomputed whenever a change is merged)
> 
> If a change is still wanted it can be restored by clicking on the Restore 
> button.
> - %< -
> 
> I would like to propose the following configuration [2] for auto-abandon:
> 
> changeCleanup.abandonAfter: 30d
> changeCleanup.abandonIfMergeable:   default (true)
> changeCleanup.cleanupAccountPatchReview:default (false)
> changeCleanup.abandonMessage:   default
> changeCleanup.startTime:Sat 00:00
> changeCleanup.interval: 1 day
> 
> If you are opposed to the use of Auto-abandon, please propose an alternative 
> method to clean up the backlog of reviews on VPP master and maintain a 
> reasonably sized queue.
> If you approve of the concept, please respond with a +1.
> If you approve of the concept but don't like the configuration, please 
> respond with your preferred configuration.
> 
> Lack of response will be interpreted as approval of the use of auto-abandon 
> with the proposed configuration ;)
> 
> Thanks,
> -daw-
> 
> [0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query 
> status:open project:vpp branch:master --format=JSON --no-limit | tail -1
> {"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
> [1] https://gerrit.fd.io/r/c/vpp/+/1529
> [2] 
> https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup
> [3] 
> https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18613): https://lists.fd.io/g/vpp-dev/message/18613
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Chris Luke via lists.fd.io]

+1

I used to do this manually, in effect, though I’ve been less active the past 
while which probably accounts for the growth!

FWIW, I usually performed it on an approximate 60 day nudge and 90 day abandon, 
about once a month, schedule. I did similar with JIRA but less frequently. I 
felt the warning of impending abandonment important enough to make the effort 
to do it, though my recollection suggests that in one case did it actually 
result in a proposal being revived.

Chris.

From: vpp-dev@lists.fd.io  On Behalf Of Dave Wallace
Sent: Wednesday, January 27, 2021 16:50
To: vpp-dev@lists.fd.io
Subject: [EXTERNAL] [vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP 
master

Folks,

There are currently 636 open Gerrit Reviews on VPP master [0], the oldest being 
submitted on Jun 13, 2016 [1]!

I would like to propose that the Gerrit Review Auto-Abandon job [2] to reduce 
the size of the queue to a more reasonable length. Benefits include (from [3]):

- %< -
Abandoning old inactive changes has the following advantages:

it signals change authors that changes are considered outdated

it keeps dashboards clean

it reduces the load on the server (for open changes the mergeability flag 
is recomputed whenever a change is merged)

If a change is still wanted it can be restored by clicking on the Restore 
button.
- %< -

I would like to propose the following configuration [2] for auto-abandon:

changeCleanup.abandonAfter: 30d
changeCleanup.abandonIfMergeable:   default (true)
changeCleanup.cleanupAccountPatchReview:default (false)
changeCleanup.abandonMessage:   default
changeCleanup.startTime:Sat 00:00
changeCleanup.interval: 1 day

If you are opposed to the use of Auto-abandon, please propose an alternative 
method to clean up the backlog of reviews on VPP master and maintain a 
reasonably sized queue.
If you approve of the concept, please respond with a +1.
If you approve of the concept but don't like the configuration, please respond 
with your preferred configuration.

Lack of response will be interpreted as approval of the use of auto-abandon 
with the proposed configuration ;)

Thanks,
-daw-

[0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query 
status:open project:vpp branch:master --format=JSON --no-limit | tail -1
{"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
[1] 
https://gerrit.fd.io/r/c/vpp/+/1529<https://urldefense.com/v3/__https:/gerrit.fd.io/r/c/vpp/*/1529__;Kw!!CQl3mcHX2A!WKZvy1VX3DtS0oUkHHYuKP-zneXVpYoPgG3k0GlwcibFOoR3rZaJ_tZikj3l639t6A$>
[2] 
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup<https://urldefense.com/v3/__https:/gerrit-review.googlesource.com/Documentation/config-gerrit.html*changeCleanup__;Iw!!CQl3mcHX2A!WKZvy1VX3DtS0oUkHHYuKP-zneXVpYoPgG3k0GlwcibFOoR3rZaJ_tZikj0hI7sH3w$>
[3] 
https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon<https://urldefense.com/v3/__https:/gerrit-review.googlesource.com/Documentation/user-change-cleanup.html*auto-abandon__;Iw!!CQl3mcHX2A!WKZvy1VX3DtS0oUkHHYuKP-zneXVpYoPgG3k0GlwcibFOoR3rZaJ_tZikj2CEK7oSA$>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18611): https://lists.fd.io/g/vpp-dev/message/18611
Mute This Topic: https://lists.fd.io/mt/80171630/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] RFC: Enabling Gerrit Auto-Abandon job on VPP master

[Dave Wallace]

Folks,

There are currently 636 open Gerrit Reviews on VPP master [0], the 
oldest being submitted on Jun 13, 2016 [1]!


I would like to propose that the Gerrit Review Auto-Abandon job [2] to 
reduce the size of the queue to a more reasonable length. Benefits 
include (from [3]):


- %< -
Abandoning old inactive changes has the following advantages:

    it signals change authors that changes are considered outdated

    it keeps dashboards clean

    it reduces the load on the server (for open changes the 
mergeability flag is recomputed whenever a change is merged)


If a change is still wanted it can be restored by clicking on the 
Restore button.

- %< -

I would like to propose the following configuration [2] for auto-abandon:

changeCleanup.abandonAfter:          30d
changeCleanup.abandonIfMergeable:        default (true)
changeCleanup.cleanupAccountPatchReview: default (false)
changeCleanup.abandonMessage:            default
changeCleanup.startTime:                 Sat 00:00
changeCleanup.interval:          1 day

If you are opposed to the use of Auto-abandon, please propose an 
alternative method to clean up the backlog of reviews on VPP master and 
maintain a reasonably sized queue.

If you approve of the concept, please respond with a +1.
If you approve of the concept but don't like the configuration, please 
respond with your preferred configuration.


Lack of response will be interpreted as approval of the use of 
auto-abandon with the proposed configuration ;)


Thanks,
-daw-

[0] dwallacelf@daw-server-2:~$ ssh -p 29418 gerrit.fd.io gerrit query 
status:open project:vpp branch:master --format=JSON --no-limit | tail -1

{"type":"stats","rowCount":636,"runTimeMilliseconds":1467,"moreChanges":false}
[1] https://gerrit.fd.io/r/c/vpp/+/1529
[2] 
https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#changeCleanup
[3] 
https://gerrit-review.googlesource.com/Documentation/user-change-cleanup.html#auto-abandon

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18609): https://lists.fd.io/g/vpp-dev/message/18609
Mute This Topic: https://lists.fd.io/mt/80169540/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-