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 s...@dague.net / sean.da...@samsung.com http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev