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[1] 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? > > Eek! > > 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. -- nigelb _______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
