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