I think there are two opposing goals about the development process here: on the one hand it should be as thoroughly designed and implemented as possible and on the other hand the community wants many new features as quickly as possible. We have done more of the former in the beginning of the ROS 2 development and then more recently - based on the feedback of the community - changed more towards the later. The desire for a fast development pace comes with the side effect that a first implementation of a concept might not be the final perfect solution. But I think that is absolutely fine. That is why ROS distributions exist. While the API in each distribution stays stable a newer ROS distribution has the freedom to break them in order to move forward.
For ROS 1 - which is around for 10+ years - it is reasonable to expect that "core" API doesn't usually change between distros - or if it does that it aims for a tick tock cycle. For ROS 2 which is much less mature I don't think this is required at all. Just because a certain feature has been implemented doesn't imply it is final by any means. ROS 2 is too young to assume everything is stable / mature and not changing. As long as changes are clearly documented it can be expected from packages using the API to follow those instructions (e.g. for [Dashing](
https://index.ros.org/doc/ros2/Releases/Release-Dashing-Diademata/#changes-since-the-crystal-release)) in order to support future ROS distros.
The two features mentioned - lifecycle and actions - are good example of the process. There has been a significant amount of discussion and iteration on the design documents themselves as well as on the pull requests implementing these features. But most of the current concerns have not been raised during that multi-months time. These kind of feedback often only comes up way later when a bigger audience is trying to use the new functionality which I think is natural. Would it be great of these aspects would have been brought up and addressed earlier in the process? For sure. But the fact that they didn't come up earlier shouldn't prevent us from iterating on the design as well as the implementation in the future as needed. If this would imply "change the whole concept of how this is implemented" that would be unfortunate but if the reasoning behind that need is sound it should probably be done.
Regarding the question about the venue / forum for this kind of discussions: imo these already exist in various forms. There is the design repo with already merged, pending or to-be-created issues and PR, the actual tickets implementing specific features as well as this Discourse category. All these can be used to discuss topics like this. You referenced two specific tickets where this exact kind of discussion is actually happening. The main step missing from these discussions is imo a follow up in terms of someone taking the lead to act on the discovered shortcomings and working towards improving them. And ultimately this is very often limited due to resource constraints as well as lack of initiative.
---
[Visit Topic](
https://discourse.ros.org/t/design-process-of-ros-2/7782/3) or reply to this email to respond.
If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates.
______________________________________________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
Unsubscribe: <
http://lists.ros.org/mailman//options/ros-users>
(text/plain)