Jack, Thanks for the perspective. We are a small team and we are working very hard. Florian, We understand that some of the limits on new users can be frustrating, however these limits are important to keep spam away. And these techniques are quite standard, and we only have a few hours in the day to fight spam and do development. I have updated the FAQ to include easy ways to work around the linking issue. [1] And if your question title is being flagged as not descriptive enough that suggests that it is definitely too short. Answers.ros.org is an instance of askbot an open source project hosted at askbot.org. If you have feedback or features, such as the search, for the core engine please use the Askbot forums. [0] I generally use google or the tags. JD, Looking at the build times for packages on the build farm using the old buildsystem both in groovy and fuerte, the groovy one is faster for arm_navigation [2]. I also compared ackerman_msgs as an example of a small dry package [3] and groovy is also faster (Note by the names I just picked two from the top of the list I knew to be using the old buildsystem. I just put these up here to show that although there are parts of the buildsystem which are slower it's not actually 18x slower overall. ) I wrote a long description of why the specific commands referenced in the questions are slower. The top level view is that to keep from disrupting existing rosbuild packages rosmake/rospack now has to be able to walk 3 different package systems, rosbuild, catkin, and rosdep. If you want more details see the paragraph after the references. I don't know any specifics about orocos incompatibility. We've reached out to the orocos development team to get more feedback since you have mentioned it. Catkin is built specifically to be more general than rosbuild so I expect that we can work through any known issues. With respect to the software engineering quality, that is going to be a specific upcoming focus of ongoing development. If you have suggestions for how we can improve our practices please participate when the brainstorming gets started. A lot of the responsibility lies on the individual package maintainers and we're looking at how to provide them with the best procedures, tools, and incentives to keep the quality up. There are obviously things which can be improved upon and we appreciate your feedback. There's an open pull request to switch the caching to make rosdep faster which should help [4] and we will continue to speed things up as much as possible in the future. Tully [0] http://askbot.org/en/questions/ [1] http://answers.ros.org/faq/ [2] http://jenkins.willowgarage.com:8080/view/FbinP64/job/ros-fuerte-arm-navigation-experimental_binarydeb_precise_amd64/buildTimeTrend VS http://jenkins.willowgarage.com:8080/view/GbinP64/job/ros-groovy-arm-navigation-experimental_binarydeb_precise_amd64/buildTimeTrend [3] http://jenkins.willowgarage.com:8080/view/FbinP64/job/ros-fuerte-ackermann-msgs_binarydeb_precise_amd64/buildTimeTrend VS http://jenkins.willowgarage.com:8080/view/FbinP64/job/ros-groovy-ackermann-msgs_binarydeb_precise_amd64/buildTimeTrend [4] https://github.com/ros/rosdep/pull/222 With respect to the speed of rosmake, we were aware that it would take slower. This was a compromise to allow it to have full functionality building on packages from both the new and old build systems, so as not to disrupt the compile of existing packages. There was a very large effort to make sure that the old buildsystem can work on top of the new buildsystem. The issues is that in the new buildsystem the distinction between ROS dependencies and system dependencies has been dropped, since ROS packages can now be treated as system dependencies in many situations. However, packages in the old buildsystem are now required to query the new and old buildsystem as well as system dependencies each run. This basically adds a fixed cost to every build of a package. rospack was highly optimized for repeated calls, and the new buildsystem is noteably faster in the overall performance and one of the primary ways it did that was to reduce the repeated calls to walk the dependency tree. To make this same sort of performance boost we could completely rewrite the old rospack based buildsystem, however rewriting the old buildsystem doesn't make a lot of sense when we already have a replacement which is fundamentally faster and cleaner. I was not aware of this question on answers.ros.org and that there could be that much of a slowdown. The buildfarm And the link to packages taking 7 seconds to build vs 149 is a very large difference, however it's also approximately the worst case. The packages being python based every build is a no-op, leaving only the package traversal times. If there was real compile content the relative slowdown would be much smaller. On Mon, Feb 18, 2013 at 7:15 PM, Jack O'Quin wrote: > > On Mon, Feb 18, 2013 at 12:10 PM, Yamokoski, JD (JSC-ER)[OCEANEERING SPACE > SYSTEMS] wrote: > > Software as complex and as large as ROS will have some bumps and bruises >> at a major release - but from the outside looking in, it appears as though >> too much was changed in this release (as evidenced by the above plus the >> longer than normal release cycle). Sweeping changes are obviously needed to >> keep up with new use cases or changing requirements. But more care needs to >> be taken by those in the driver seat. With the size of the ROS community >> and its popularity, more weight should be given to minimizing disruption >> rather than favoring the hot new shiny stuff. Disruption breeds discontent >> - discontent leads to searching for alternatives. And the only way projects >> like ROS work is with a strong community involvement. For once, one of >> these component-based approaches to robotics has finally taken off (and >> history is full of failed previous attempts). I don't want to see it happen >> again. >> > > Thanks for your perspective, John. I share your high hopes for ROS. > > You are not the only one unhappy with the disruption caused by the catkin > build system migration in Fuerte and Groovy. But, some perspective may help > guide our frustrations into more-productive channels. > > First, let me say that I applaud the hard work done by the > small core group of ROS developers who continue working very hard on this > transition. I suspect there are significantly fewer of them than most > people here realize. > > With the OSRF picking up responsibility for ROS from Willow Garage, there > may be additional disruptions, but there is also an opportunity to move > forward. I hope they will hire some more full-time developers to help those > who are working so hard already. Even more importantly, OSRF may be able to > mobilize the large contingent of competent, committed ROS community members > so we can contribute more effectively. > > What can we do to help? The Hydro release is coming soon. It looks like > mostly a bug fix and stabilization distribution, which makes a lot of sense > at this point. We can all contribute by opening issues to document every > single problem we encounter, providing patches to fix them whenever > possible. > > As mentioned earlier in this thread, the ros.org/wiki and answers.ros.orgsites are experiencing difficulties, too. Maybe they have outgrown some of > their original design limitations. They clearly need lots of tender loving > care. This is one area in which more community involvement can certainly > help. We can fix many of those problems ourselves. Other problems may > require specialized access, but can be reported by whoever finds them: > > https://github.com/ros-infrastructure/roswiki/issues > https://github.com/ros-infrastructure/answers.ros.org/issues > > I am not giving up on ROS, just because we've had a rough patch, lately. > And, I hope you won't, either. > -- > joq > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > -- Tully Foote tfoote@willowgarage.com (650) 475-2827