On Wed, 2014-01-22 at 17:59 -0500, Sean Dague wrote: > 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.
Both good points. -jay _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev