Open Stack

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 <fungi at 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" <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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>