On Saturday, July 18, 2015 at 7:51:52 PM UTC+2, Jack O'Quin wrote:On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:
On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.
I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.
I know, I am not tired of the community requesting this. I am tired of OSRF using that as an excuse for creating a new competing middleware.
There are multiple interpretations of what the community means when it says "We want less disruptions in the future":
A) Do not improve ROS1, create a new competing middleware to which we'll have to slowly and painfully migrate.
B) Put all future improvements into ROS1, but make the changes backwards compatible and well-tested.
I believe B reflects better than A what the community wants.
There is also C:
C) Create yet another middleware if you must, but continue to improve ROS1, and make changes to ROS1 backwards compatible and well-tested
But C obviously requires much more effort to everyone, and is not realistic. As as you can see with catkin and ament, it is very tempting for OSRF to just leave ROS1 behind, and make improvement only in the ROS2 world. You can also read it in all the OSRF answers saying: "Improving catkin could have caused regressions, so we did not improve catkin". With that argument, no further improvements will be made to ROS1. The same goes for all other packages maintained outside OSRF with the expectable low level of code sharing.
The alternative that the community could well have expected would be to make the communication layer exchangeable under a common client API (which can be changed/enhanced over time using tic-toc deprecation). That would mean all further improvements would have benefitted the community, but the community would not have to change much or migrate. This is the obvious benefit of maximum code sharing.
Apparently OSRF does not want to do that, and the consequence will be a huge disruption to the ROS community, as opposed to the wish expressed by the community.
Note that this is not fatal to anyone, and maybe in 10 years people will look back and praise OSRF for the courage and wisdom. I only explain that this is the opposite of what the community wants now.
That's what I mean when I say I am tired of the "non-disruptive of ROS1" argument.
--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
On Saturday, July 18, 2015 at 7:51:52 PM UTC+2, Jack O'Quin wrote:On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:
On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.
I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.
I know, I am not tired of the community requesting this. I am tired of OSRF using that as an excuse for creating a new competing middleware.
There are multiple interpretations of what the community means when it says "We want less disruptions in the future":
A) Do not improve ROS1, create a new competing middleware to which we'll have to slowly and painfully migrate.
B) Put all future improvements into ROS1, but make the changes backwards compatible and well-tested.
I believe B reflects better than A what the community wants.
There is also C:
C) Create yet another middleware if you must, but continue to improve ROS1, and make changes to ROS1 backwards compatible and well-tested
But C obviously requires much more effort to everyone, and is not realistic. As as you can see with catkin and ament, it is very tempting for OSRF to just leave ROS1 behind, and make improvement only in the ROS2 world. You can also read it in all the OSRF answers saying: "Improving catkin could have caused regressions, so we did not improve catkin". With that argument, no further improvements will be made to ROS1. The same goes for all other packages maintained outside OSRF with the expectable low level of code sharing.
The alternative that the community could well have expected would be to make the communication layer exchangeable under a common client API (which can be changed/enhanced over time using tic-toc deprecation). That would mean all further improvements would have benefitted the community, but the community would not have to change much or migrate. This is the obvious benefit of maximum code sharing.
Apparently OSRF does not want to do that, and the consequence will be a huge disruption to the ROS community, as opposed to the wish expressed by the community.
Note that this is not fatal to anyone, and maybe in 10 years people will look back and praise OSRF for the courage and wisdom. I only explain that this is the opposite of what the community wants now.
That's what I mean when I say I am tired of the "non-disruptive of ROS1" argument.
On Sat, Jul 18, 2015 at 10:51 AM, Jack O'Quin <jack....@gmail.com> wrote:On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:
On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.
I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.
Thank you, Jack, for stating it that clearly.I really hope that we (as the whole community) reaches a consensus on this part: that it is a *requirement* and not an argument to discuss about for longer.
I believe the impetus for ROS 2 comes mainly from a different, more industrial product development community, who would like to use ROS but for various reasons cannot in its current form.This is somewhat over-simplified and just my opinion (OSRF speak quite well for themselves). But, if I am correct, the initial ROS 2 target users are not the research labs who make up much of the existing ROS 1 community.The academics I know want stability so they can run their experiments and publish papers. They do not care much about low-level infrastructure, and begrudge every minute spent upgrading. They hated the catkin migration. It was time-consuming, and for them rosbuild actually worked better.Many product developers want new features, like DDS, and light-weight C language interfaces with few dependencies. They need their wire-level protocols fully documented, sometimes even verified and certified. They are less interested in ease of migration from ROS 1.Why not just build separate products for the different user communities? That is generally easier to do. But, both the research and development communities stand to benefit from synergy between the two versions.Whenever we separate academia and industry usage we do that based on the "common" use cases of those two domains.
We should keep in mind that academy might very well have use cases that are not well supported in ROS 1 and therefore would like to use ROS 2.The same goes for industry: for a few applications ROS 1 might be well suited.In general I agree to your command that initially it is likely that "academia" will stay with ROS 1 for a while and industrial users might start considering ROS 2 if they avoided ROS 1 for good reasons.But I don't this has to be the case for long.Wherever "academy" (or any other ROS 1 user) has use cases which are not satisfied well enough in ROS 1 - to name a few:* communication over unreliable / wireless network* multi robot scenarios* real time requirements* integration with embedded systemsI am certain they will consider to use ROS 2 since it is supposed to fulfill these requirements much better compared to ROS 1.Simply because it will get them to their goal faster and with less effort.
On Sun, Jul 19, 2015 at 3:40 AM, Thibault Kruse <tibo...@googlemail.com> wrote:On Saturday, July 18, 2015 at 7:51:52 PM UTC+2, Jack O'Quin wrote:On Sat, Jul 18, 2015 at 5:09 AM, Thibault Kruse <tibo...@googlemail.com> wrote:
On Friday, July 17, 2015 at 12:56:12 PM UTC+2, William Woodall wrote:On Fri, Jul 17, 2015 at 1:49 AM, Thibault Kruse <tibo...@googlemail.com> wrote:So the already tight maintainership situation in ROS will become even tighter, as maintainers will have to split their time, or support only one side of the trench.As one of the major contributors and maintainers of ROS 1 (even before doing it full time) I'm keenly aware of this. I, and I'm certain many others, agree with the sentiment, but I'm not sure how else to reconcile this with the fact that we need to continue to make improvement to the core of ROS in order to meet the needs of more users. I think the approach we've taken will be slower and require more effort on our part and on the communities part, but it will also be the least risky and least disruptive to the ROS 1 ecosystem.
I am a bit tired of hearing this "non-disruptive of ROS1" argument. Basically ROS2 is the preparation for the mother of all disruptions to the ROS1 ecosystem. A slow, large-scale migration of thousands of packages to a different middleware. I believe it would be more honest if OSRF said that OSRF prefers disruption by migration over disruption by evolution, or something.ROS 1 non-disruption is not an argument. It is a requirement that has been forcefully communicated to OSRF by many (probably most) of the current ROS 1 community.
I know, I am not tired of the community requesting this. I am tired of OSRF using that as an excuse for creating a new competing middleware.
There are multiple interpretations of what the community means when it says "We want less disruptions in the future":
A) Do not improve ROS1, create a new competing middleware to which we'll have to slowly and painfully migrate.
B) Put all future improvements into ROS1, but make the changes backwards compatible and well-tested.
I believe B reflects better than A what the community wants.
There is also C:
C) Create yet another middleware if you must, but continue to improve ROS1, and make changes to ROS1 backwards compatible and well-tested
But C obviously requires much more effort to everyone, and is not realistic. As as you can see with catkin and ament, it is very tempting for OSRF to just leave ROS1 behind, and make improvement only in the ROS2 world. You can also read it in all the OSRF answers saying: "Improving catkin could have caused regressions, so we did not improve catkin". With that argument, no further improvements will be made to ROS1. The same goes for all other packages maintained outside OSRF with the expectable low level of code sharing.
The alternative that the community could well have expected would be to make the communication layer exchangeable under a common client API (which can be changed/enhanced over time using tic-toc deprecation). That would mean all further improvements would have benefitted the community, but the community would not have to change much or migrate. This is the obvious benefit of maximum code sharing.
Apparently OSRF does not want to do that, and the consequence will be a huge disruption to the ROS community, as opposed to the wish expressed by the community.
Note that this is not fatal to anyone, and maybe in 10 years people will look back and praise OSRF for the courage and wisdom. I only explain that this is the opposite of what the community wants now.
That's what I mean when I say I am tired of the "non-disruptive of ROS1" argument.You're right that all three of those paths are possible. And they have been considered. All of the options have tradeoffs. If we break the API we can make fundamental changes to the design. If we require full backwards compatibility and roll it out in place it limits how much change can be made, and also risks breakage of the current system as it changes underneath. And obviously we can do both or some combination of both it just takes more work.
Our decision was based on feedback from users and potential users. We specifically reached out to ROS users as well as people and companies we know have chosen not to use ROS so we could identify the use cases not supported by the current version of ROS.
Our goal is to use the lessons learned from the many years of use of ROS to create a replacement which will have compelling enough features that people will want to migrate their software forward. If they do not find the new features compelling they can keep using the current system. If we develop a system that we cannot convince people to use that will be a major failure and we can switch our development back to the ROS 1.0 branch.
On Sun, Jul 19, 2015 at 3:40 AM, Thibault Kruse <tibo...@googlemail.com> wrote:
[...]
I think you are contradict yourself here.On the one hand you argue for having future changes in ROS 1 but in a backward compatible way.But on the other hand you suggest to use a tic-toc cycle to introduce changes.
--
You received this message because you are subscribed to the Google Groups "ROS SIG NG ROS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-ng-ro...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.