Oops hit send to early. 1) git-review shows some community guidelines 2) auto-review of known lower-quality patches
And those do relieve some reviewer burden. On Fri, Sep 22, 2017 at 12:43 PM, Jeremy Freudberg <jeremyfreudb...@gmail.com> wrote: > You're right. The amount of wasted reviewer time is far more > drastic+problematic then the amount of "wasted" CI resources. > > My prior email did contain these suggestions: > > > On Fri, Sep 22, 2017 at 11:04 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: >> On 2017-09-22 14:50:55 +0000 (+0000), Rajath Agasthya (rajagast) wrote: >>> On 9/21/17, 10:19 PM, "Jeremy Freudberg" <jeremyfreudb...@gmail.com> wrote: >>> > 3) Delay spin-up of resource-intensive/long-running CI jobs >>> > until after some initial review has been added or time has >>> > passed. Authorized contributors, not necessarily synonymous with >>> > cores, can override the delay if there's a critical patch which >>> > needs to get through the queue quickly. >>> >>> +1. This is done in Go code review process, where CI is run by an >>> explicit Run-TryBot+1 review only after a core developer >>> ascertains that the patch looks okay and most code review comments >>> are addressed. This means no CI resource usage for every change >>> and every single patchset. We could adopt a similar approach so >>> that CI resources aren’t wasted for useless patches. This doesn’t >>> take a whole lot of work for the reviewers than the current review >>> process. >>> >>> https://github.com/golang/go/wiki/GerritAccess#trybot-access-may-start-trybots >> >> I'm wary of potential overengineering like this, particularly >> without at least some analysis showing the percentage of CI >> resources we'll save by asking our already overworked (on most teams >> anyway) core reviewers to also take on the task of authorizing basic >> CI jobs. The more likely outcome I foresee is that, much like >> contributions going unreviewed sometimes for weeks or months, the >> change authors won't even know whether their changes are suitable >> for review for some similar period of delay. >> >> The CI system is there to serve reviewers and contributors, not the >> other way around. The CI resource shortages we see from time to time >> should not be used as an excuse to go on witch hunts so we can find >> ways to save what probably accounts for <1% of our overall >> utilization. That's classic premature optimization. What's important >> in this situation is the time wasted by reviewers having to respond >> to or find ways to ignore these patches, so let's focus on that >> rather than getting bogged down with attractive non-problems for >> which we can more easily engineer technical solutions. >> -- >> Jeremy Stanley >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev