Open Stack

On 2017-09-22 14:50:55 +0000 (+0000), Rajath Agasthya (rajagast) wrote:
> On 9/21/17, 10:19 PM, "Jeremy Freudberg" <jeremyfreudberg at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: Digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170922/b695219b/attachment.sig>