In the Open MPI face-to-face meeting we had a long discussion about how to
better harness MTT such that new failures are identified and the community
alerted to their existence. The current manual way is not working. Our
ultimate goal here is to know if we are making forward progress, and if
something new fails the community knows about it immediately and

We had a bunch of discussion and decided to think it over some more then
come back to a teleconf in the next week or two to make a plan. The MTT
group is scheduled to meet on Thursday, July 20 at 4 pm EST. We already
know that doesn't work for everyone interested so I setup a doodle poll to
pick a time for this specific discussion.

*Please fill out the doodle poll by Thursday, July 13, 2017 at 5 pm EST.
I'll pick a time then.*

Three topics were identified to make progress.
 1. Move MTT (Perl) Client to new server submission interface
 2. Adding an "expected fail" list to MTT Client.
 3. Drive the number of MTT reported failures to 0

(1) This will start the movement to the new RESTful MTT server. Eventually
we want to disable the old PHP submission mechanism. This is a first step.
Josh needs to re-test this interface to confirm it is still working as
expected with the existing 'v3' database.

(2) For each branch/test-suite/runtime-configuration identify a test run as
"known to fail". These will be flagged in the MTT Database and MTT
Viewer/Reporter as separate from other failures ("failed, but we expected
to pass"). Is this part of the INI file or a separate 'thing'?

(3) The idea is that the "failed, but we expected to pass" number should be
0 for all sites. The individual site is responsible for maintaining their
"known to fail" list. If the "failed, but we expected to pass" number is >0
then this is a 'new failure' and an email to the community is generated.

Josh Hursey
IBM Spectrum MPI Developer
mtt-devel mailing list

Reply via email to