A periodic conference call among the maintainers and developers of OpenCyphal is to take place every Friday at 17:00 UTC at https://meet.jit.si/OpenCyphal.
Wednesday, April 22, 2020 5:00 PM TZ
Please post your feedback and suggestions here.
2 Likes
Point of order, is there a reason we use “appear.in” and not google meetings?
I missed the meeting today due to Norway changing from daylight saving time this weekend and this unexpectedly “moved” the meeting one hour for me.
If anyone has a notes/minutes from the meeting I would like to see it.
I do have notes from the previous meetings. We should probably find a place to collaborate creating the Agenda and storing notes from meetings for future reference.
I expected the DST switch to cause complications. Luckily, a fix is coming. 
Point of order, is there a reason we use “appear.in” and not google meetings?
No reason other than that appear.in is marginally easier to set up on my computers. I am open to using Google or whatever else is preferred.
If anyone has a notes/minutes from the meeting I would like to see it.
Look out for my posts on this forum and on the pending PR’s on GitHub.
This time it was my turn to miss this due to timezone change. Sorry.
My questions for the call were the following:
- where are we with the si namespace? How do we close on this?
- The previous si proposal lacked torque. Can we add torque in nm?
- Code-compatibility - it’s time to close on this. If my latest proposal isn’t palatable then I’ll go with the BDFL and just accept @pavel.kirienko 's judgement.
- I added a counter proposal for transfer priority mnemonics, fyi.
- What can I do to close on the v1 standard? I’d really like to get back to work on libuavcan.
where are we with the si namespace? How do we close on this?
See my latest comment in the thread: SI namespace design. 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
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.
Vote on the new time (multiple choice):
- Mon 17:30 UTC
- Mon 18:00 UTC
- Mon 18:30 UTC
- Tue 17:30 UTC
- Tue 18:00 UTC
- Tue 18:30 UTC
- Wed 17:30 UTC
- Wed 18:00 UTC
- Wed 18:30 UTC
- Thu 17:30 UTC
- Thu 18:00 UTC
- Thu 18:30 UTC
- Fri 17:30 UTC
- Fri 18:00 UTC
- Fri 18:30 UTC
0 voters
I added meeting notes as a topic for now, we will discuss on the meeting tomorow if the layout is fine or should be changed: Weekly dev call - Meeting notes
Look at us failing to reach a consensus:
Can we please reconsider the above shown options? @kjetilkjeka any chance to make Tuesday work? @scottdixon how about Wednesday?
Tuesday before 15:30 UTC or after 19:30 UTC will work fine for me, but I guess that doesn’t match up well with your time zones.
I would also be able to make a Sunday meeting at 17:30 or 18:00 GMT (or any convenient time), but I guess that’s no good for Scott.
Let’s discuss it at the meeting today.
Hello @kjetilkjeka @pavel.kirienko @scottdixon - Would there be an opportunity for me to join one of these calls to align on some things NXP is hoping to do?
@iain.galloway by all means. The next call is scheduled on Nov 21 18:00 UTC. We didn’t have one today because we just changed the schedule from Mon 18:00 UTC to Wed 18:00 UTC, the previous call was two days ago on Monday.
There will be no dev call next week on Dec 26 due to holidays in EU and the US. The next dev call is scheduled on Jan 2.
Is there going to be a call on Jan 23rd? What time and timezone? I am working to get two apps engineers to join to talk about S32K146 support. Alternatively we could have a separate core team meeting.
The dev calls are held every Wednesday at 18:00 UTC, as described in the OP post. The meeting room is at https://appear.in/Zubax. The next call is expected to take place on Jan 23rd as usual.
I am working to get two apps engineers to join to talk about S32K146 support.
This is wonderful. We should have at least @scottdixon for coordination with his Libuavcan rewrite effort.
1 Like
Scott has reported difficulties connecting via appear.in today. If anyone else couldn’t join the call today because of issues with appear.in, please reply here. We might consider abandoning this service in favor of a more robust solution.
It turned out that my camera driver locked up when I tried to connect the first time. My guess is Google Chrome is more to blame then appear.in.
Pavel, great to see that there are dev calls for uavcan. Unfortunately time for Asia/Australia people is really bad. For example me UTC 18.00 + Bangkok 8hrs is 2am. Are there any possibilities to make calls a few hours earlier ?
1 Like
It is proposed to have the weekly call a few hours earlier. Please indicate what suits you:
(poll cancelled, see below)
Paging @scottdixon @iain.galloway