Open Stack

On 01/22/2014 05:52 PM, Clint Byrum wrote:
> Excerpts from Jay Pipes's message of 2014-01-22 13:43:41 -0800:
>> On Wed, 2014-01-22 at 15:39 -0500, Sean Dague wrote:
>>> <snip>
>>> ==========================
>>> Executive Summary
>>> ==========================
>>> To summarize, the effects of these changes will be:
>>>
>>>  - 1) Decrease the impact of failures resetting the entire gate queue
>>>    by doing the heavy testing in the check queue where changes are not
>>>    dependent on each other.
>>>
>>>  - 2) Run a slimmer set of jobs in the gate queue to maintain sanity,
>>>    but not block as much on existing bugs in OpenStack.
>>>
>>>  - 3) As a result, this should increase our confidence that changes
>>>    put into the gate will pass. This will help prevent gate resets,
>>>    and the disruption they cause by needing to invalidate and restart
>>>    the whole gate queue.
>>
>> All good things, Sean ++.
>>
>> Might I also suggest one other thing that, IMO, would reduce gate
>> contention?
>>
>> What if we added an option to git review that would inject something
>> into the git commit message that would indicate the patch author felt
>> the patch does not need to have integration testing run against it.
>>
>> Lots of patches make no substantive code changes and just clean up
>> style, comments, or documentation. Having integration tests run for
>> these patches is just noise and provides no value. There should be a way
>> to indicate to Zuul not to run integration testing if some marker is in
>> the commit message.
>>
> 
> I love the idea here, that there are changes that are not in fact
> changing behavior.
> 
> However, I am wary of asking reviewers to add another item to the review
> checklist. Because not only do they then need to check to see if it is
> being used improperly, but that it is not being used properly. This is
> a "humans: be better" change. So if it were to be done, the humans would
> need some tools.
> 
> We could, however, do something fairly interesting with the automation
> we do have. We could probably use some software analysis tools to make
> a reasonable recommendation. We can use a tool such as radon to measure
> whether the change actually changes McCabe complexity, or Halstead volume,
> and thus is a good candidate for the trivial change flag.
> 
> Anyway, I like the optimization as long as it doesn't just shift more
> load onto core reviewers.

I think that if you want to head down this road, the point shouldn't be
to make trivial changes skip the tests. It should be to put trivial
changes into a holding pen, and squash them down and bulk process them
in one go. Then they still get tested, but at much less cost.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/3bf80e92/attachment.pgp>