[ros-users] answers.ros.org is the hell

Wed Feb 20 01:01:46 UTC 2013

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<http://jenkins.willowgarage.com:8080/view/FbinP64/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 <jack.oquin at gmail.com> wrote:

>
> On Mon, Feb 18, 2013 at 12:10 PM, Yamokoski, JD (JSC-ER)[OCEANEERING SPACE
> SYSTEMS] <john.d.yamokoski at nasa.gov> 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/roswiki/issues?sort=created&state=open>
>  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 at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>

-- 
Tully Foote
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130219/218ac678/attachment-0004.html>