2023 12 05 Eclipse iceoryx developer meetup

Eclipse iceoryx developer meetup

Date: 2023/12/05

Time: 17:00 CET

Link: https://app.element.io/jitsi.html#conferenceDomain=meet.element.io&conferenceId=JitsiVtfrqukadefbqiqfxryxabai&userId=&roomId=!AooDAAwkyNWwkMElpt%3Agitter.im&roomName=eclipse%2Ficeoryx&startWithAudioMuted=true&startWithVideoMuted=true&language=en

Attendees

• Simon Hoinkis, Apex.AI
• Graham Palmer, Latitude AI
• Dietrich Krönke, Apex.AI
• Matthias Killat, Apex.AI
• Mathias Kraus, ekxide

Agenda

1. Look at the open tasks from previous meetings, 10 min, Mathias
   • Move to C++17
   • Update link in governance.md to the new element based video chat
   • Adding the new meeting date to the ROS 2 calendar
   • Update iceoryx.io to inform about the new Rust implementation - maybe also register iceoryx.rs - how to restructure iceoryx.io for the new Rust implementation
   • Eclipse self service for iceoryx - not critical and can be done when we have time
2. Shall we move the classes from dust back to iceoryx_hoofs or iceoryx_hoofs/experimental or iceoryx_hoofs/addons, 10 min, Christian
   • this will simplify the ROS release
3. Which additional packages to release, 15 min, Simon
   • Cyclone DDS gateway
   • bindings like ARA COM, RMW and Rust
   • ROS release?
4. Remove test IDs, 10 min, Christian
5. If there is time, talk about a common coding style for iceoryx, 15 min, Mathias
   • currently it is different for parts of hoofs and the rest of the codebase
   • see also
     • https://github.com/eclipse-iceoryx/iceoryx/wiki/2022-10-13-Eclipse-iceoryx-developer-meetup
     • https://github.com/eclipse-iceoryx/iceoryx/wiki/2022-10-27-Eclipse-iceoryx-developer-meetup
     • https://github.com/eclipse-iceoryx/iceoryx/wiki/2023-03-02-Eclipse-iceoryx-developer-meetup
   • proposal
     • CamelCase for classes to prevent confusion with STL types
     • snake_case for free functions and methods
     • snake_case for variables and members (members with a m_ prefix)
     • snake_case for type traits, they are similar to variables in template meta-programming after all
     • CamelCase for enums
     • SCREAMING_SNAKE_CASE for enum tags
     • SCREAMING_SNAKE_CASE for constants
   • it's basically what we have now but defines one style in case there are currently two in use
     • snake_case for some classes and methods in hoofs and dust
     • CamelCalse for classes and lowerCamelCase for methods in the remaining codebase
     • since the API surface in posh is smaller than in hoofs or dust, going with snake_case for methods should have the lesser impact than the other way around
     • we can provide a using declaration for classes with snake_case during the v3 lifetime with a doxygen deprecation warning
     • deprecate snake_case classes with v4 using the C++ deprecate attribute
     • if someone wants to keep the snake_case classes it is a simple using declaration in their code
     • for methods and functions we could think of a similar strategy

Minutes

2. Move dust classes to hoofs
   • we need to specify which AUTOSAR rules we follow
   • we need to have a list of classes/header the rules are applied to
   • maybe also a matrix which indicate
     • coverage (>30, >50, >80)
     • static analyzer (clang-tidy, Axivion)
   • revisit after v3.0 release
3. Release with v3.0
   • Cyclone DDS maybe
   • ARA COM maybe, Simon
   • RMW iceoryx, Simon
   • iceoryx-rs maybe, Mathias
   • ROS release? to be decided later, currently there is not much of a benefit
4. Necessary evil. We would need to have an alternative solution before they can be removed
5. postponed to next meeting

Topics for next meetings

1. Move C-binding to separate repo?
   • #2030