"expected" regression test failures are back again in the trunk - are people actively working on it - would be nice to have a clean tinderbox run.

[Mike Matrigali <mi...@sbcglobal.net>]

I believe it is a bad state for all developers when the nightly 
regression tests are failing.  I understand intermittent errors, and
maybe even one off environment errors.  But it would be nice if we
tried really hard to at least have the tinderbox runs be clean, we
were there for a few months but looks like with all the work on 10.3
the trunk has back stepped a bit.  For those experienced it may not
be much work to look at the diff and say "oh, that is the one that is
ok to ignore", but for new developers I think it sets the wrong 
expectation that it is ok to check in and cause regressions.

I believe active work is taking place trying to resolve the junit errors
for DERBY-2925, so it is probably reasonable to allow that work to
continue rather than backing out the change.

What about DERBY-2916, the issue with the wisconsin test.  Best I can
determine some people looked at it briefly when the change that broke
it went in 3 weeks ago.  Is anyone actively looking at it?
Should we:
o leave it as is and cause diff pain across many platforms and developers.
o back out the change
o change the master given that best guess by those that looked at it 
think that it is ok (Given the discussion in the bug this is what I
am leaning toward unless someone with expertise thinks that is a bad
idea).
o stop running the test until someone can look at the bug?
o Also what is the right JIRA settings, I sort of agree that the issue
   may be minor but since it is causing all developers running tests
   pain I would like to raise it somehow.  Would raising the urgency on
   regression test failures to blocker or urgent be appropriate?

Re: "expected" regression test failures are back again in the trunk - are people actively working on it - would be nice to have a clean tinderbox run.

[Rick Hillegas <Ri...@Sun.COM>]

Mike Matrigali wrote:
> I believe it is a bad state for all developers when the nightly 
> regression tests are failing.  I understand intermittent errors, and
> maybe even one off environment errors.  But it would be nice if we
> tried really hard to at least have the tinderbox runs be clean, we
> were there for a few months but looks like with all the work on 10.3
> the trunk has back stepped a bit.  For those experienced it may not
> be much work to look at the diff and say "oh, that is the one that is
> ok to ignore", but for new developers I think it sets the wrong 
> expectation that it is ok to check in and cause regressions.
>
> I believe active work is taking place trying to resolve the junit errors
> for DERBY-2925, so it is probably reasonable to allow that work to
> continue rather than backing out the change.
>
> What about DERBY-2916, the issue with the wisconsin test.  Best I can
> determine some people looked at it briefly when the change that broke
> it went in 3 weeks ago.  Is anyone actively looking at it?
> Should we:
> o leave it as is and cause diff pain across many platforms and 
> developers.
> o back out the change
> o change the master given that best guess by those that looked at it 
> think that it is ok (Given the discussion in the bug this is what I
> am leaning toward unless someone with expertise thinks that is a bad
> idea).
> o stop running the test until someone can look at the bug?
> o Also what is the right JIRA settings, I sort of agree that the issue
>   may be minor but since it is causing all developers running tests
>   pain I would like to raise it somehow.  Would raising the urgency on
>   regression test failures to blocker or urgent be appropriate?
This would be a new use for the Urgency field. It mostly surfaces as a 
gating flag at release time.

Just as a reference, here's a pointer to a discussion last year about 
JIRA fields: 
http://www.nabble.com/Jira-field-definition-clarification-for-Derby-tf2024859.html#a5567827