-
Notifications
You must be signed in to change notification settings - Fork 391
2023 12 05 Eclipse iceoryx developer meetup
Mathias Kraus edited this page Dec 5, 2023
·
4 revisions
Date: 2023/12/05
Time: 17:00 CET
- Simon Hoinkis, Apex.AI
- Graham Palmer, Latitude AI
- Dietrich Krönke, Apex.AI
- Matthias Killat, Apex.AI
- Mathias Kraus, ekxide
- 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
- Shall we move the classes from
dust
back toiceoryx_hoofs
oriceoryx_hoofs/experimental
oriceoryx_hoofs/addons
, 10 min, Christian- this will simplify the ROS release
- Which additional packages to release, 15 min, Simon
- Cyclone DDS gateway
- bindings like ARA COM, RMW and Rust
- ROS release?
- Remove test IDs, 10 min, Christian
- 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
anddust
- CamelCalse for classes and lowerCamelCase for methods in the remaining codebase
- since the API surface in
posh
is smaller than inhoofs
ordust
, 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
- snake_case for some classes and methods in
- 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
- 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
- Necessary evil. We would need to have an alternative solution before they can be removed
- postponed to next meeting
- Move C-binding to separate repo?
- #2030