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
