<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> IMO we would be better off going the scripted way to remove the subset<br>
> of cases we can automate and catch the rest with manual edits and in review.<br>
<br>
I do not see a point of automating ourselves if there is an existing<br>
automation that works much better than anything we can do ourselves.<br></blockquote><div><br></div><div>I agree. At least as a starting point. Poring over a patch is easier than poring over the whole source</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I like a few things the tool does. But so far it seems like something we<br>
> want to run across the code occasionally. eg as a Jenkins test job.<br>
<br>
Yes, or a Semaphore CI job, and/or on-demand. Please clarify regarding<br>
performance-* checks above. If we are in agreement regarding<br>
modernize-use-override and at least one more check, then I can start<br>
working on a polished proposal for those checks (at least) and the<br>
overall setup.<br></blockquote><div><br></div><div>I'm also fine with running it manually every now and then. Our rate of change is not such that we would introduce regressions all that often.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">    Francesco</div></div>