Open Stack

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