[openstack-dev] Changes coming in gate structure

Sean Dague sean at dague.net
Wed Jan 22 22:59:43 UTC 2014

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 Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com

-------------- 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>

More information about the OpenStack-dev mailing list