where are we with the si namespace? How do we close on this?
See my latest comment in the thread: SI namespace design - #5 by pavel.kirienko. We could use a competing namespace design proposition to compare against my original one.
The previous si proposal lacked torque. Can we add torque in nm?
By all means.
Code-compatibility - it’s time to close on this. If my latest proposal isn’t palatable then I’ll go with the BDFL
Will reply in the same thread once more tomorrow: The case for code compatibility - #4 by pavel.kirienko
What can I do to close on the v1 standard? I’d really like to get back to work on libuavcan.
I think we agree on all things except the versioning issue. The SI namespace does not seem to affect implementations. I think it should be safe for you to start working on the new implementation already, meanwhile I and Kjetil will finish up the spec – Kjetil will take care of the DSDL chapter, whereas I will update the transport layer and the high-level overview sections in the beginning of the document.
Kjetil proposed to move the call to 18:30 UTC. It works well for me during the winter, so I am okay with the change for now; when the DST is active it will get difficult though (18:30 UTC is 21:30 EEST, which is rather late). Perhaps we could pick an earlier time instead, or maybe a different day, to avoid rescheduling the call once again in a few months when the DST is active again. Otherwise, 18:30 UTC works as a tentative solution.