Lloyd Chambers wrote:
> I have two other points I'll make here:
>
> 1) The real failure is not running QL before integrating. That's a
> process problem. Such things happen, that's life.
>
> 2) "The solution to failing tests is to remove the tests". An
> interesting idea that carries other risks.
No, the solution should have been to undo the changes that caused the
regression. If that's not done because the change is more important than
than the feature that's broken, then file a bug and temporarily don't
run the test that fails. That way we don't waste each others' time.
Sahoo
>
> Abhijit should make the call on disabling the tests, but I'd prefer he
> establishes a written policy as part of our process guidelines. It's
> not my call, it's his, I stand ready to do whatever he decides.
>
> I'm not looking for more discussion here, I'm satisfied with whatever
> Abhijit wants to do.
>
> Lloyd
>
> On Sep 8, 2009, at 8:53 AM, Lloyd Chambers wrote:
>
>> There is hardly unanimous agreement here.
>>
>> How much time is wasted? Seems like a false assumption. Is this
>> failure so hard to understand?
>>
>> testAMXComplianceMonitorFailureCount___KNOWN_FAILURE_20090904_ISSUE_9355_IGNORE_FOR_NOW
>>
>>
>> So when the test is disabled, *more* bugs can go in undetected?
>> There is a larger picture to be understood.
>>
>> =====> Abhijit should make the call.
>>
>> Lloyd
>>
>> On Sep 4, 2009, at 9:48 PM, Sahoo wrote:
>>
>>> I agree with Kedar. Look the amount of time wasted because of a
>>> known failure. We can keep a bug open to ensure that the test is
>>> re-enabled.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Kedar Mhaswade wrote:
>>>> I was suggesting a temporary disablement so others can continue with
>>>> their chores. It's lame too to expect a known failure to show up.
>>>> So, I vote for (temporarily) disabling it.
>>>>
>>>> Lloyd Chambers wrote:
>>>>> Abhijit is trending strongly towards disabling the test for this
>>>>> reason (confusion).
>>>>>
>>>>> They indicate real problem with the ORB MBeans, but not problems
>>>>> that affect the overall server operation.
>>>>>
>>>>> So what it comes down to is what our policy in removing tests that
>>>>> detect real problems? I think it's kinda lame to have tests, then
>>>>> turn them off when real problems crop up.
>>>>>
>>>>> My other suggestion was to have the test itself emit a message
>>>>> indicating that it is a known issue.
>>>>
>>>> But still, I won't know if the failure is because of the fact that
>>>> there is a known cause for it or because my changes are (also) causing
>>>> it.
>>>>
>>>>>
>>>>> I have NOT seen amxtest.AMXCoreTests.iterateAllSanityCheck() fail,
>>>>> so that one needs looking into.
>>>>>
>>>>> Lloyd
>>>>>
>>>>> On Sep 4, 2009, at 1:54 PM, Kedar Mhaswade wrote:
>>>>>
>>>>>> I get the failure with:
>>>>>> amxtest.AMXCoreTests:testAMXComplianceMonitorFailureCount
>>>>>>
>>>>>> It's not clear if that's the same as the one reported in 9355.
>>>>>>
>>>>>> BTW, can we temporarily disable the test so that we get a clean
>>>>>> run every time? When the bug is fixed, we can re-enable it.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Jane Young wrote:
>>>>>>> I know #2 is a known issue. See IT 9355
>>>>>>> and
>>>>>>> http://gf-hudson.sfbay.sun.com/hudson/job/gf-trunk-build-continuous/2205/artifact/bundles/QL-GP-report.html
>>>>>>>
>>>>>>> I'm not sure about #1. Are you getting total of 2 failures or 1?
>>>>>>
>>>>>>> Richard S. Hall wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I am trying to make sure that Felix 2.0 is ready for release.
>>>>>>>> My latest run comes up with the following QL failures:
>>>>>>>>
>>>>>>>> 1. iterateAllSanityCheck
>>>>>>>> java.lang.NullPointerException
>>>>>>>> at
>>>>>>>> amxtest.AMXCoreTests.iterateAllSanityCheck(AMXCoreTests.java:94)
>>>>>>>> 2. testAMXComplianceMonitorFailureCount
>>>>>>>> java.lang.AssertionError: Server indicates that there are
>>>>>>>> non-compliant AMX MBean validator failures, failure count = 20,
>>>>>>>> examine the server log for failures
>>>>>>>> at
>>>>>>>> amxtest.AMXCoreTests.testAMXComplianceMonitorFailureCount(AMXCoreTests.java:112)
>>>>>>>>
>>>>>>>>
>>>>>>>> Are these normal failures in GF trunk?
>>>>>>>>
>>>>>>>> -> richard
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>> Lloyd Chambers
>>>>> lloyd.chambers_at_sun.com
>>>>> GlassFish Team
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> Lloyd Chambers
>> lloyd.chambers_at_sun.com
>> GlassFish Team
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish Team
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>