nigelb at redhat.com
Fri Sep 2 14:48:25 UTC 2016
On Fri, Sep 02, 2016 at 08:39:14AM -0400, Kaleb S. KEITHLEY wrote:
> On 09/02/2016 06:36 AM, Nigel Babu wrote:
> > Here's the flow as I see it:
> > 1. Propose a review request.
> > 2. Smoke tests run as soon as a patchset is created or updated.
> > 3. Reviewer gives +2.
> > 4. Zuul will run regressions in the order than patches received Code Review +2.
> > If they pass regression, Zuul will merge them into the branch requested. The
> > documentation has a good visualization that will help.
> > 5. If the regression fails, we can still do a retry. Zuul will retry the job on
> > top of the existing patch queue rather than in isolation.
> A full _regression_? Which takes hours? And is prone to spurious errors?
> Wouldn't a smoke, or just a compile (or rpmbuild) suffice for this?
> Don't we already have periodic (hourly) regressions of the head of
> master? Maybe we should have the same for the release branches?
We already only merge after NetBSD-regression and CentOS-regression have voted
back. All I'm changing is that you don't need to do the merge manually or do
Verified +1 for regression to run.. Zuul will run the tests after you get
Code-Review +2 and merge it for you with patches ordered correctly.
More information about the Gluster-infra