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
signature.asc
Description: Digital signature
__________________________________________________________________________ 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