Infra team,
Given that the regression is always overloaded and spurious failures are
always haunting us, can we try this out? We should also try to have a
separate smoke verified flag just to give enough confidence to the
reviewers as Jeff pointed out in this thread.
-Atin
Sent from one plus one
On 16-Jun-2015 19:22, Aravinda avish...@redhat.com wrote:
+1 for running regressions on need basis.
Also we need to make the tests more intelligent so that same tests runs
differently when triggered nightly/regular.
function test_some_functionality
{
if env.NIGHTLY {
# run
+1 for running regressions on need basis.
Also we need to make the tests more intelligent so that same tests runs
differently when triggered nightly/regular.
function test_some_functionality
{
if env.NIGHTLY {
# run nightly tests
# time consuming tests
# test with
Hi all,
The recent rush of reviews being sent due to the release of 3.7 was a
cause of frustration for many of us because of the regression tests
(gerrit troubles themselves are another thing).
W.R.T regression 3 main sources of frustration were,
1. Spurious test failures
2. Long wait times
3.
On 06/15/2015 04:19 PM, Kaushal M wrote:
Hi all,
The recent rush of reviews being sent due to the release of 3.7 was a
cause of frustration for many of us because of the regression tests
(gerrit troubles themselves are another thing).
W.R.T regression 3 main sources of frustration were,
On Monday 15 June 2015 04:19 PM, Kaushal M wrote:
Hi all,
The recent rush of reviews being sent due to the release of 3.7 was a
cause of frustration for many of us because of the regression tests
(gerrit troubles themselves are another thing).
W.R.T regression 3 main sources of frustration
On 06/15/2015 06:49 AM, Kaushal M wrote:
...
Current auto-triggering of regression runs is stupid and a waste of
time and resources. Bring in a project gating system, Zuul, which can
do a much more intelligent jobs triggering, and use it to
automatically trigger regression only for changes
I should have made this clearer in the steps I listed.
Under the 2nd step (I should have numbered as well), I've mentioned
that Zuul will report back the status of smoke/pre-review tests. This
is the Verified+1. Though I was thinking of using different flags, we
can use Verified it self to
On Mon, Jun 15, 2015 at 10:09:33AM -0400, Jeff Darcy wrote:
As long as there's some visible marking on the summary pages to
distinguish patches that have passed smoke vs. those that haven't, I
think we're good.
gerrit manual says you can add more comulns like revview and verified.
--
A change would get a +2 from a maintainer only once the maintainer
believes that the patch is ready to be accepted. To be at this level
of confidence, the change would have been reviewed thoroughly, and
such a generally wouldn't fail regression (excluding spurious
failures). If there was something
10 matches
Mail list logo
