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.

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.

 - Ken



On Mon, Aug 16, 2010 at 11:55 AM, Jack O'Quin <jack.oquin@gmail.com> wrote:
> This looks like a good time to reorganize the code in our
> utexas-art-ros-pkg svn repository.
>
> I want it to look more like ros-pkg, with separate trunk/, branches/
> and tags/ for each stack, so stacks can be released independently.
>
> We also have experimental ("sandbox") packages used by students for
> semester projects. I don't want them showing up in the
> http://www.ros.org/browse/list.php package list until they reach some
> level of maturity and documentation. That list is getting cluttered
> with too many undocumented packages that look like semester projects,
> which makes it hard to find packages that are genuinely reusable by
> others.
>
> Right now, we avoid this problem by putting only documented packages
> into the main repository trunk. The ROS wiki tools pick up only those
> packages, and ignore the contents of branches/sandbox.
>
> But, I can't find a clear statement of exactly what the wiki tools
> will publish if I reorganize our svn tree. I did look, but maybe not
> in the right places. I remember some discussion of this on the list a
> while back, but can't recall the particulars. I believe there was a
> way to specify which paths to publish.
>
> So, what are the recommended "best practices" for federated package
> repositories?
> --
>  joq
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>