Skip to content

2023 12 05 Eclipse iceoryx developer meetup

Mathias Kraus edited this page Nov 21, 2023 · 4 revisions

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

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. Remuve 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
    • 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

Clone this wiki locally