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.


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

Attachment: signature.asc
Description: PGP signature

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to