On 15:04 Sep 22, Jeremy Stanley 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.
+1 Can you imagine the number of jobs that would be delayed. At least today with things not be delayed we can see if a patch ever worked when it was rebased in the CI comments. -- Mike Perez
signature.asc
Description: PGP 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