I was wondering at what time folks feel its appropriate to move the default GitHub branches from ROS1 to ROS2 for projects that support both. Given Noetic is coming out shortly and the last ROS1 distribution, I think now’s a great time to consider migrating all default behavior to ROS2. This is both for practical reasons that most new development should probably be occurring in ROS2, and also highlight all of the great work early folks did in migrating packages to ROS2. Having the default branch as a ROS2 LTS distribution sends a signal that this project is available and working in ROS2. If alot of projects do this, they’ll think its a movement, and that’s what it is!
So I would like to propose that for all the ros-* repos or larger projects, rather than changing the default branches from melodic-devel -> noetic-devel we migrate them to foxy-devel. For awhile now, I’ve made all of my non-ros-* repos do this, but it seems like with Foxy its a good time to migrate all of them.
One of my goals of this post was to find some consensus so that it wouldn’t just be project specific. If we did that, even 5 years from now I doubt there would be a consistent transition over to this. I’d rather work to make some general rules on this for the ros-* repos so that its not just up to maintainers.
If its just up to me, all the things I maintain I’ll move over right now. The goal wasn’t just to do that unilaterally but see what the feeling was across the ecosystem outside of my bubble.
I think that to some degree it must be project-specific, though. For each project, what “ROS 2 support equal or greater than ROS 1 support” means will be different - especially when you consider direct ports, complete rewrites, and the spectrum in between.
There are some aspects that could be broadly defined, such as “the ROS 2 version has reached quality level X as defined in REP 2004”.
I would say it’s too early. I’m in favor of a single date that marks ‘this is when you should really start new projects in ROS2’ to push switching over, but I think if you would do that now, a lot of people would switch back and simply shrug ROS2 off as ‘under heavy development’ and not look at it again for a few years. From what I’m hearing, that’s definitely what people’s recent opinions have been: ‘from what I’ve heard it’s a mess’ and ‘they’re trying to do everything instead of focusing on a few things and doing those well’.
The switch to linking documentation from ROS 1 to ROS 2 should be when the benefits of using ROS2 for the everyday ROS user (not us devs) outweigh the disadvantages (lack of packages, tutorials, forum posts, stability). It doesn’t feel like we’re really close to that point yet.
I think that sounds like a good criteria to look at: Is “support” equal to or greater. That’s pretty open ended, but I think that it should be open ended. I think of support meaning
Maintainers are mostly working in it
New development is mostly in it
Has equal or higher “quality” in terms of tests, CI, linting, etc
So if I were to say something like: I maintain XYZ repo and I mostly use ROS2. I ensure that any new PRs for ROS1 are cherry picked to ROS2. The ROS2 branches have CI set up and run the available tests and ROS2 styling linters. Would you think @gbiggs that that is sufficient criteria? That describes a large number of ros-perception repos.
You are a core ROS dev, not a user. If anything, you’re prone to being subjective IMHO. I’ve played with ROS2 myself and have come to my own conclusions. I can see which packages have a ROS2 version, and I see many more that don’t have one.
But that’s not the point. What you need to understand is that it’s the public perception what matters, not your perception or how it actually is. I’m just providing you with data points from other folks around me who’ve voiced their views on ROS2. There’s no written quotes on that. I’m providing you what is hopefully valuable feedback. Simply dismissing that as ‘reference missing’ means you don’t want to hear it and so you’re not really open to discussion here.
I feel this is a big chicken-and-egg problem (and @smac seems to want to break that), but I believe @Achllle has a valid point: people who work with and on ROS have a rather biased view of things (perhaps privileged almost?).
Not just because they are invested and have an interest in seeing it succeed, but also because they are much, much better informed as to its current state, what is and what isn’t possible and supported, what the roadmap contains (and where things are relative to that roadmap) and, last but not least (and this has been discussed in Shape the Future of ROS 2 Documentation as well), don’t experience the large gap between being able to compile and run the examples/demos and knowing how to build ROS applications themselves.
An example of this is the nr of issues on ROS 2 repositories (and on ROS Answers) where the poster reports a build issue which in the end turns out to be caused by them trying to compile master (or whichever branch) on Dashing/Eloquent/some_other_version. If you’re aware of the development practices, it’s obviously clear you should not do this and should checkout the appropriate branch. But it is apparently not so obvious to many users. And this is just one example, there is a myriad of things which are not obvious, unless you are part of the scene.
Changing the default branches to the ROS 2 ones just like that is going to contribute to the perception of things being underdocumented, underdeveloped and being “a mess” (note I wrote the perception, although in some cases it’s unfortunately true).
When should the change be made? I don’t know actually. But I do agree with @gbiggs that we cannot force this on “all of ROS” (whatever that means).