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: 

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]

Hi Paul,

My original motivation for this proposal is to improve the stability and 
availability of the CI system by not abusing it through lack of queue 
maintenance.


The situation exists today because there is fundamentally a shortage of 
committer bandwidth to complete code reviews.  This is exacerbated by 
the poor signal-to-noise ratio of the gerrit queue due to the size as 
well as by the growing reluctance to merge patches for which a committer 
is not a maintainer. [Thanks Benoit for pointing that out.]


IMHO, it is the responsibility of both the author of a patch and the 
maintainers/committers in the community to complete the review/merge 
cycle.  As a committer, I am personally reluctant to merge patches more 
than 30 days old because they have not been tested with the latest 
code.  A best practice would be for an author rebase any patches that 
have not been verified in a couple of weeks.  This not only has the 
benefit of re-testing the patch with the latest merged code, it moves 
the patch to the top of the gerrit queue where it is most visible.


In the past, I worked on an open source project which had a 7 day 
auto-abandon policy.  It took me a while to get used to it, but it 
worked quite effectively.  Feedback on patches was timely and the queue 
only contained patches which were actively ready for review. For VPP, I 
think that 7 days is way too short but as a maintainer of the CI, I 
believe it is important find a way to automatically protect the CI 
system which has been overly fragile.


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.


I fully understand that enabling auto-abandon in gerrit results in a 
bias towards preserving committers' time over submitters' time, but I 
think it is worth trying as it has the potential provide a positive 
benefit for both the stability of the CI and the management of the 
gerrit queue.


Thanks,
-daw-

On 1/29/2021 9:28 AM, Paul Vinciguerra wrote:

I am a firm -1.
I already have a python script that generates maintainers, but I would 
rather we look at the maintainer plugin which was contributed to 
gerrit by Cisco. https://gerrit.googlesource.com/plugins/maintainer/ 



As to Andrew's point, it is just as fair to propose that if a 
maintainer hasn't addressed a verified +1 in T+30, it is merged and it 
is then it will become a priority to the maintainer.


About a month or so ago, Ole +2'd and merged a change of mine that has 
been sitting for 2 releases, because Andrew -1'd for doing some 
testing and then left it.  Thank you, Ole.


When I first became a comitter, I submitted a change that Danjan -1'd 
that the feedback was that it was agreed to not accept.  Damjan +2'd 
and committed it on his own some 10 months later.  Thank you, Damjan.


There is a change in the system https://gerrit.fd.io/r/c/vpp/+/30559 
 that allows a user to build vpp 
if the system language is Chinese.  The author tagged the maintainer, 
and hasn't gotten a response.  I tested the patch and +1'd it to help 
save some time for the maintainer.  A week or so later, another 
comitter was tagged.  It is still sitting there.


When the question of adding worker tests to the framework came up, 
Klement sent me a link to work he had done over a year earlier that 
was never merged.


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 have MANY changes that I rely on that I cherry pick into my own 
builds.  I had a change that added the names to the established unix 
sockets for troubleshooting.  It was a good year old.  Neale saw it a 
month or so ago and merged it.  The maintainers did not.


I have uncommitted changes right now that fix issues in the build 
system that are blocking other changes from being merged.


Dave,
Let me know how I can help.

On Thu, Jan 28, 2021 at 11:36 AM Andrew Yourtchenko 
mailto:ayour...@gmail.com>> wrote:


Dave,


On 28 Jan 2021, at 16:59, Dave Wallace mailto:dwallac...@gmail.com>> 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 

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]

I am a firm -1.
I already have a python script that generates maintainers, but I would
rather we look at the maintainer plugin which was contributed to gerrit by
Cisco.  https://gerrit.googlesource.com/plugins/maintainer/

As to Andrew's point, it is just as fair to propose that if a maintainer
hasn't addressed a verified +1 in T+30, it is merged and it is then it will
become a priority to the maintainer.

About a month or so ago, Ole +2'd and merged a change of mine that has been
sitting for 2 releases, because Andrew -1'd for doing some testing and then
left it.  Thank you, Ole.

When I first became a comitter, I submitted a change that Danjan -1'd that
the feedback was that it was agreed to not accept.  Damjan +2'd and
committed it on his own some 10 months later.  Thank you, Damjan.

There is a change in the system https://gerrit.fd.io/r/c/vpp/+/30559 that
allows a user to build vpp if the system language is Chinese.  The author
tagged the maintainer, and hasn't gotten a response.  I tested the patch
and +1'd it to help save some time for the maintainer.  A week or so later,
another comitter was tagged.  It is still sitting there.

When the question of adding worker tests to the framework came up, Klement
sent me a link to work he had done over a year earlier that was never
merged.

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 have MANY changes that I rely on that I cherry pick into my own builds.
I had a change that added the names to the established unix sockets for
troubleshooting.  It was a good year old.  Neale saw it a month or so ago
and merged it.  The maintainers did not.

I have uncommitted changes right now that fix issues in the build system
that are blocking other changes from being merged.

Dave,
Let me know how I can help.

On Thu, Jan 28, 2021 at 11:36 AM Andrew Yourtchenko 
wrote:

> 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 

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
> 
> 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 

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/Documentation/config-
gerrit.html#changeCleanup
[3] https://gerrit-review.googlesource.com/Documentation/user-change-

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]
-=-=-=-=-=-=-=-=-=-=-=-