[ros-users] best practices for ROS package repositories?

Jürgen Sturm sturm at informatik.uni-freiburg.de
Thu Aug 19 08:36:39 UTC 2010


Hi Jack, Ken,

I was thinking about the same problem for the package list on ROS.org
and our ALUFR-ROS-PKG repository. I think that it is good practice to
place unfinished or only partially working packages in a sandbox
folder, and not to index them (or at least mark them as
"sandbox/unstable" on ROS.org.

Regarding the sheer number of packages that will appear for ROS in the
next years, I think that a good solution would be to somehow compute
some automatically extracted features that help users to find/sort
packages more easily. May I propose the following features to be added
to the package list (and the package wiki page):

1. last commit date (or time since last commit)
2a. number of other packages that depend on this package
2b. latest commit date of dependent packages
3a. number of packages that depend on this package from other institutions
3b. latest commit date of dependent packages from other institutions

This list is not complete, but this would help me to recognize how old
packages are, how well maintained, and how useful.

Cheers
Juergen


On Tue, Aug 17, 2010 at 5:36 AM, Jack O'Quin <jack.oquin at gmail.com> wrote:
> On Mon, Aug 16, 2010 at 2:13 PM, Ken Conley <kwc at willowgarage.com> wrote:
>> Hi Jack,
>>
>> Right now, the only rule is that we will index whatever URL you give
>> us for your repo. Some repos use svn externals; in rare cases we index
>> multiple URLs.
>>
>> We're working on bringing up a better toolchain to support releases
>> and more structure to external repositories. If this toolchain works,
>> it means that you will be able to use the same tools that we use
>> internally here to manage the structure of our repositories in
>> conjunction with releases and documentation. If you'd like to be a
>> tester for this, let me know.
>>
>> There are two parts/phases to bringing up this toolchain:
>>
>> Phase 1: releases: supporting external releases of stacks into ROS
>> distribution. This allows them the same access to deb-building,
>> auto-generation of rosinstall files, etc...
>>
>> Phase 2:  documentation: right now we manually maintain the list of
>> repositories that we index for rosbrowse. After we're sure we have
>> phase 1 right, we transition rosdoc/rosbrowse to support rosinstall
>> files. This should kill two birds with one stone: the rosinstall file
>> that rosdoc/browse use could be the same rosinstall file you use for
>> people to install your repo, and could be the same rosinstall file
>> that our toolchain above generates.
>
> That sounds good. Thanks.
>
> I am glad to help with testing (although I won't want to reorganize
> our repo again until after the fall semester).
>
>> We try not to make blanket statements on how repositories have to be
>> organized. We've chosen to organize our repos the way we have because
>> we have 50+ researchers, engineers and interns working across very
>> different areas of development and at different levels. We have to
>> keep a careful balance of exploratory development and focused
>> engineering, and we're still tuning that balance. There are also
>> multiple organizations using GIT instead of SVN, and GIT has very,
>> very different usage patterns.
>
> Sounds like we should leave things mostly the same for this coming
> semester. With one URL for the repository it all needs to stay
> together.
>
> That's OK, we don't have that many developers, so we can release all
> the stacks in sync without much problem. I don't see any reason to
> define a separate URL for each stack at this point. Once phase 2 is
> available we can revisit the tree structure.
>
> Regards,
> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>



More information about the ros-users mailing list