search

canonical / multipass-blueprints

Blueprint definitions for [`multipass launch`](https://multipass.run)
GNU General Public License v3.0
66 stars 38 forks source link

Add ros2-jazzy #49

Open artivis opened 2 months ago

artivis commented 2 months ago

This PR adds a blueprint to setup a ROS 2 Jazzy environment (which is based on 24.04).

It is analogous to https://github.com/canonical/multipass-blueprints/pull/29.

townsend2010 commented 2 months ago

Hey @artivis,

Thanks for this!

I think we discussed this previously with the ROS and ROS2 Blueprints, but we really don't want to have a bunch of similar Blueprints available. We really need a strategy that can have something like "sub-Blueprints", but we aren't there yet. For now, I think no more than 2 similar Blueprints at the same time will make it less confusing for users. These Blueprints show up for everyone and users not familiar with what ROS is will be confused by ros-noetic, ros2-humble, and if we were to take this, ros2-jazzy.

Is it still important to have ros2-humble? I ask because perhaps we can remove that one in favor of this one.

artivis commented 2 months ago

Hi @townsend2010,

I get your point.

Let me start by saying that those blueprints shouldn't be confusing for the targeted audience. The ROS project follows the same release cycle as Ubuntu. As such they have an LTS release based on each Ubuntu LTS. This new blueprint, jazzy, is the new ROS 2 LTS based on 24.04. As such it cannot really replace humble which is based on 22.04. Similarly noetic is the ROS 1 LTS release based on 20.04. They are not interchangeable and each have a user base.

So I guess at this point it's either a matter of figuring out a mechanism of sort (such as the sub-Blueprints you mention) or deciding to intentionally dropping support for one (or several) Ubuntu release(s). Keeping in mind that, e.g., noetic will phase out once multipass stop supporting 20.04 etc.

townsend2010 commented 2 months ago

Hey @artivis,

Let me start by saying that those blueprints shouldn't be confusing for the targeted audience. For sure. What I'm concerned about is all of the other users. I can imagine a scenario where users not familiar with what ROS is sees a bunch of these in multipass find and then think these must be very important (which they are to the targeted audience) since there are so many of them. Then they launch them and then wonder what they re supposed to do. This whole UX needs to be solved, but that is for another day.

Until we are at that point, my opinion is that we should only have two of these, but ideally this is a product decision. Unfortunately, we have no PM, so we are kind of stuck and need to make our best guess:)

artivis commented 1 month ago

As discussed, #56 removes the ROS Noetic blueprint in favor of this one.

ricab commented 1 month ago

Thank you @artivis, we'll have this reviewed soon.

georgeliao commented 1 month ago

Hi @artivis Thanks for this. I have tested the blueprint. It worked well on Linux. However, about merging it, because it uses image 24.04, I think we need to wait for the multipass 1.14 release, see https://github.com/canonical/multipass-blueprints/issues/53 for details. @ricab, shall we keep the PR like this and just approve it? Same goes to https://github.com/canonical/multipass-blueprints/pull/56.

artivis commented 1 month ago

@georgeliao Thanks for the feedback.
That's perfectly fine with me :+1:

ricab commented 1 month ago

Yup, that sounds good @georgeliao, thanks!