Meeting minutes
Minutes
McCool: We can't review the minutes right now, since they are broken.
<McCool> Apr-6
<kaz> (kaz fixes the permission of the minutes)
mm walks through the minutes. Kaz fixes permission issue for the minutes.
McCool: any objections regarding the minutes?
… no objections.
Guidelines for manual.csv
McCool: Ege, do you want to update the assertion tester?
Ege: There is this annoying pipeline issue. When I am lucky I notice it. I have to check if I am able to automate this.
some discussion between mm and ek regarding the assertion tester.
Ege: The state has to be aligned between 3 different repositories. It adds some complexities, because they all have to up to date all the time.
Philipp: I am not well aware of the details. But can't you use a submodule instead of 3 different repositories?
McCool: ek, can you write more about this?
ek explains some details of the tester and csv files.
<McCool_> Update manual.csv for TD, document pipeline
McCool: Document the process first is probably the best right now.
manual csv guidelines
Ege: Some assertions in the text are good enough. And some other things are more complex.
McCool: Some things could be a MUST, but they are actually optional, because this MUST relies on being used in the first place.
McCool: For now, you should just merge it. I am going to go over it and create a separated PR if necessary.
mm merged #289
Ditto manual csv assertion
McCool: We should go through the security later.
<McCool_> remove duplicate assertions
<McCool_> which did some cleanup in the manual assertions, removing duplicates
Organization
<kaz> open Issues
McCool: We should close some issues and not keep them around.
McCool: ek, any things we should close?
Ege: We use the wiki and github to track issues. I think github isn't a proper way to manage the projects.
McCool: There are still issues hanging around that should be archived and later delete.
Philipp: How about, as action item, that everyone gets through their own issue and closes them, if not relevant anymore.
McCool: We have the label proposed-closing. We can mark them and then go through them.
McCool: For next time people can go through their own issues and close them if not relevant. But someone has to make the work and label them.
Home Assistant
McCool: I want to build a retail demo. We want to also use Node-Red integration.
McCool: I bought several sensor and devices compatible with HomeAssistant. I exposed them over HomeAssistant as TDs.
McCool: I want to go through the HomeAssistant API, because it exposes some issues.
… HomeAssistant uses Bearer tokens, which is good. We want to use that as well.
… I want to add the necessary features in order to be exposed as a TDD. A read only TDD
Philipp: Have you looked into the implementation Jan wrote? From my experience it is the better implementation.
node-red-contrib-wot-discovery extension
mm goes through some details of HomeAssistant and the mapping to WoT TDs
McCool: I make some progress, but it isn't a clean 1to1 mapping. That adds some complexity.
kaz given we have 5 more minutes, we should clarify the next steps. First, when we could start to ask people to give their feedback? Second this home assistant topic might be rather part of the Plugfest topic than Testing, but how should we proceed with that direction?
McCool: Yes, it is.
McCool: For the manual.csv we have to wait until it is frozen. We should also search for stale conversions.
Kaz: For the implementation reports itself. Can we ask the people for feedback on those?
McCool: I haven't regenerated them yet. We should probably ask people to do manual csvs. They could finish them until the end of the week.
Ege: People shouldn't wait for manual.csv to be stable, because the spec isn't stable.
McCool: When I see manual csvs, I merge them.
<kaz> [adjourned]