Open Stack

Oops hit send to early.

1) git-review shows some community guidelines
2) auto-review of known lower-quality patches

And those do relieve some reviewer burden.

On Fri, Sep 22, 2017 at 12:43 PM, Jeremy Freudberg
<jeremyfreudberg at gmail.com> wrote:
> 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
>>