<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 9, 2020, 1:02 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, May 9, 2020 at 2:09 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br>
><br>
> On 9/5/20 11:30 am, Gedare Bloom wrote:<br>
> > On Wed, May 6, 2020 at 5:12 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>> wrote:<br>
> >><br>
> >><br>
> >>> On 6 May 2020, at 8:15 pm, Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> >>><br>
> >>> On 06/05/2020 12:00, Chris Johns wrote:<br>
> >>><br>
> >>>>> On 6/5/20 7:35 pm, Sebastian Huber wrote:<br>
> >>>>>> On 06/05/2020 10:41, <a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a> wrote:<br>
> >>>>><br>
> >>>>>> From: Chris Johns<<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>><br>
> >>>>>><br>
> >>>>>> Updates #2962<br>
> >>>>>> ---<br>
> >>>>>>    bsps/powerpc/psim/config/psim-testsuite.tcfg | 22 ++++++++++++++++++++<br>
> >>>>>>    1 file changed, 22 insertions(+)<br>
> >>>>>>    create mode 100644 bsps/powerpc/psim/config/psim-testsuite.tcfg<br>
> >>>>>><br>
> >>>>>> diff --git a/bsps/powerpc/psim/config/psim-testsuite.tcfg b/bsps/powerpc/psim/config/psim-testsuite.tcfg<br>
> >>>>>> new file mode 100644<br>
> >>>>>> index 0000000000..b0d2a05086<br>
> >>>>>> --- /dev/null<br>
> >>>>>> +++ b/bsps/powerpc/psim/config/psim-testsuite.tcfg<br>
> >>>>>> @@ -0,0 +1,22 @@<br>
> >>>>>> +#<br>
> >>>>>> +# PSIM RTEMS Test Database.<br>
> >>>>>> +#<br>
> >>>>>> +# Format is one line per test that is_NOT_  built.<br>
> >>>>>> +#<br>
> >>>>>> +<br>
> >>>>>> +expected-fail: fsimfsgeneric01<br>
> >>>>>> +expected-fail: block11<br>
> >>>>>> +expected-fail: rbheap01<br>
> >>>>>> +expected-fail: termios01<br>
> >>>>>> +expected-fail: ttest01<br>
> >>>>>> +expected-fail: psx12<br>
> >>>>>> +expected-fail: psxchroot01<br>
> >>>>>> +expected-fail: psxfenv01<br>
> >>>>>> +expected-fail: psximfs02<br>
> >>>>>> +expected-fail: psxpipe01<br>
> >>>>>> +expected-fail: spextensions01<br>
> >>>>>> +expected-fail: spfatal31<br>
> >>>>>> +expected-fail: spfifo02<br>
> >>>>>> +expected-fail: spmountmgr01<br>
> >>>>>> +expected-fail: spprivenv01<br>
> >>>>>> +expected-fail: spstdthreads01<br>
> >>>>><br>
> >>>>> I don't think these tests are expected to fail. If they fail, then there is a bug somewhere.<br>
> >>>><br>
> >>>> Yes we hope no tests fail but they can and do. Excluding tests because they fail would be incorrect. In the 5.1 release these bugs are present so we expect, or maybe it should say, we know the test will fail. With this change any thing that appears in the failure column is "unexpected" and that means the user build of the release does not match the state we "expect" and it is worth investigation by the user.<br>
> >>>><br>
> >>>> Without these tests being tagged this way the user would have no idea where the stand after a build and test run and that would mean we would have to make sure a release has no failures. I consider that as not practical or realistic.<br>
> >>> Maybe we need another state, e.g. something-is-broken-please-fix-it.<br>
> >><br>
> >> I do not think so, it is implicit in the failure or the test is broken. The only change is to add unexpected-pass, that will be on master after the 5 branch.<br>
> >><br>
> ><br>
> > I disagree with this in principle,<br>
><br>
> I did not invent this, it is borrowed from gcc. I considered their<br>
> mature test model as OK to follow. Look for "How to interpret test<br>
> results" in <a href="https://gcc.gnu.org/install/test.html" rel="noreferrer noreferrer" target="_blank">https://gcc.gnu.org/install/test.html</a>.<br>
><br>
> We have ...<br>
><br>
> <a href="https://docs.rtems.org/branches/master/user/testing/tests.html#test-controls" rel="noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/user/testing/tests.html#test-controls</a><br>
><br>
> Is the principle the two points below?<br>
><br>
> > and it should be reverted after we branch 5.<br>
><br>
> I would like to understand how regressions are to be tracked before we<br>
> revert the change. Until this change you could not track them. We need<br>
> to capture the state somehow and I view capturing the state in the tests<br>
> themselves as the best method.<br>
><br>
> > It's fine for now to get the release state sync'd, but we<br>
><br>
> I am not following why we would only tracking regressions on a release<br>
> branch?<br>
><br>
> > should find a long-term solution that distinguishes the cases:<br>
> > 1. we don't expect this test to pass on this bsp<br>
><br>
> If a test cannot pass on a BSP for a specific reasons it is excluded and<br>
> not built, e.g. not enough memory, single core. A test is expected to<br>
> fail because of a bug or missing feature we are not or cannot fix or<br>
> implement so we tag it as expected-fail or by default the test is tagged<br>
> as expected-pass. If a test may or may not pass because of some edge<br>
> case in a BSP it can be tagged 'indeterminate'.<br>
><br>
> > 2. we expect this test to pass, but know it doesn't currently<br>
><br>
> This depends on a point in time. After a change I make I would consider<br>
> this a regression and I would need to see what I have done in my change<br>
> to cause it. For this to happen we need a baseline where the tests that<br>
> fail because of a known bug or missing feature at the time I add my<br>
> change are tagged as expected to fail.<br>
><br>
> An example is dl06 on the beagleboneblack:<br>
><br>
> <a href="https://lists.rtems.org/pipermail/build/2020-May/014695.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2020-May/014695.html</a><br>
><br>
> The RAP needs to support trampolines and it does not so the test is<br>
> expected to fail.<br>
><br>
> An example of a regression is a test that passes in a specific build<br>
> configuration and fails in another. These recent psim results from Joel<br>
> show this where the build without RTEMS_DEBUG passes and with<br>
> RTEMS_DEBUG fails. Here there are 2 regressions:<br>
><br>
> <a href="https://lists.rtems.org/pipermail/build/2020-May/014943.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2020-May/014943.html</a><br>
> <a href="https://lists.rtems.org/pipermail/build/2020-May/014946.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/build/2020-May/014946.html</a><br>
><br>
> The regression in fsrfsbitmap01.exe with RTEMS_DEBUG explains the<br>
> timeout in the no RTEMS_DEBUG version. I had not noticed this before.<br>
> They are hard to notice without a baseline in each BSP and expecting us<br>
> to have 100% pass on all BSPs in all testing configurations, especially<br>
> simulation, is too hard.<br>
><br>
> My hope is a simple rule "If you do not see 0 fails you need to check<br>
> your changes".<br>
><br>
> > They are two very different things, and I don't like conflating them<br>
> > into one "expected-fail" case<br>
><br>
> Sorry, I am not following. Would you be able to provide some examples<br>
> for 1. and 2. that may help me understand the issue?<br>
><br>
<br>
Yes. There are tests that "pass" by failing, such as the intrcritical<br>
tests.  These are tests that are expected to fail, always and forever,<br>
and are not worth looking at further if they are failing. An<br>
expected-fail that passes is, then, a bug/regression.<br>
<br>
Then there are tests we have triaged and identified as bugs, which<br>
could be tagged by something such as "known-failure" that is not<br>
expected but we know it happens. This would be like spfenv tests where<br>
the support doesn't exist yet, or like the dl06.  These are tests that<br>
should be passing some day, but they are not right now. Yes,<br>
"known-failure" encodes a notion of time, but we must have a notion of<br>
time, because a regression is time-sensitive as well. The idea of<br>
"known-failure" is just a subset of what you have added to the<br>
"expected-failure" column. It would just be another reported statistic<br>
to add just like Timeouts or Benchmarks.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'm concerned that we are not making a distinction between investigated and known failures and deficiencies which have tickets and should work if X is fixed. The Beagle issue and many of the jmr3904 failures are in this category. Known failure should indicate a certainty that it can't be made to work per someone who investigated. You can't add memory, the simulator catches an invalid access before the trap handler, etc. As opposed to all the TLS tests which fail because it isn't supported on an architecture.</div><div dir="auto"><br></div><div dir="auto">Can we make a distinction between those two conditions? Something like failure accepted pending investigation versus fails and explained versus known failure?</div><div dir="auto"><br></div><div dir="auto">Known failure has a  comment explaining it </div><div dir="auto"><br></div><div dir="auto">Maybe a known issue which has a comment and ticket.</div><div dir="auto"><br></div><div dir="auto">Pending investigation for these you are flagging. Noted as known but no explanation. Can serve as future tasks pool.</div><div dir="auto"><br></div><div dir="auto">Is that all that's needed? We don't want to lose the information that we think these likely should pass but we haven't been investigated.</div><div dir="auto"><br></div><div dir="auto">Otherwise we have lost that no one has explained the situation.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I do understand your desire to have "0" Failures as a goal, but having<br>
"0" failures does not mean there are no regressions. It also does not<br>
capture the true state of the world if we ignore known failures. I<br>
suggest redefining "0 Fail" as "0 Regression" to fit your perspective.<br>
Since an unexpected pass is also a regression. Then it can more<br>
clearly separate the cases of interest.<br>
<br>
<br>
> Chris<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>