Meeting minutes
Fady: any objections to mar 14-18, given tight timing?
Cristiano: might be out for a day, but not a problem
minutes
McCool: note that our last discussion was to have testfest feb 28-mar 4, but main call resolution was mar 14-18
… will have to discuss if that is a problem we have to fix
Fady: also need to look at details of testfest/plugfest
McCool: not hearing any objections
Fady: so the scheduling is done
testing
Fady: is feature freeze done for TD?
McCool: for both TD and Discovery, not completely, but "mostly"; enough to start with testing except for a few dangling issues
Kaz: just to confirm, have minutes been approved?
Fady: any objections?... hearing none, approved
<kaz> Jan-26
discovery testing
McCool: still distracted with final assertions, but soon
… had some test suites, but not yet integrated
… but really it's only the output files that need to be consistent; it's ok if there are multiple test suites
deliverable
McCool: suggest we focus on TD/TM and Discovery in this round
Cristiano: tm testing is just a small modification of the existing TD tests, right?
Fady: yes, that's right; working on it
Cristiano: we also need some test cases
McCool: there are some tm's checked in already
McCool: also assuming TMs will be in same implementation report
Lagally: true that profile spec is still doing another round, but there are some things that are fully spec'd and can be tested
McCool: so I think we probably could extend the assertion tester (JSON Schema + scripts), but need to identify the "frozen" assertions
Lagally: we can however set up the toolchain, etc. and get a first draft out
McCool: to clarify, I have to run the report generator
… but start by copy over wot-thing-description/testing
McCool: also want to mention the description of implementation reports in architecture needs to be updated... right now only mentions the wot-td one, but in fact this round we will have several
Kaz: as I already mentioned the other day, we should clarify which spec needs what information (=assertion tests which can be automatically checked, and manual tests which might require actual communication between exposer and consumer. we can do that based on the proposed directory structure on the GitHub but should have concrete guide for that.
McCool: also we may have to re-think the directory structure, i.e. need multiple csv files merged for each implementation
McCool: I think we need a simple way to merge results that does not depend on the assertiontester, since we won't actually have TDs to check e.g. for Discovery
logistics
McCool: need to update readme
Fady: ok, will fix
Fady: aob?
… seems is not, adjourn
<kaz> [adjourned]