On Fri, Jul 20, 2012 at 2:00 AM, Geoffrey Biggs <geoffrey.biggs@aist.go.jp>
 wrote:

> Is ROS meant to be an operating system style thing with lots of
> independent packages developed by independent teams? In this case,
> then the current approach should be maintained, and we must accept its
> warts, working around them as appropriate.
>

This is not an abstract problem that I think may happen and only
necessitates a "cross that bridge when we come to it" solution. This is a
problem that I have now experienced several times, and I think we need
concrete solutions and protocols.

Gentoo removes unmaintained packages from its repository and
> relies on them being provided by overlays managed by the people who
> care about those packages
>

Should we do what Gentoo does? This sounds like removing something from the
package index and the wiki, which I think everyone has agreed on is not
going to help the situation. The gentoo model doesn't really apply since
many ROS packages that have been blessed by a wiki listing are already
installed through overlays anyway.

I do agree that ROS should have a distributed development community, but
when you have a package listed on the wiki, you are raising it to a higher
status than say, some random package on github/bitbucket/personal vcs
server.

Consider this scenario that I have experienced:
1) Developer A releases package, has it indexed on the ROS wiki
2) Developer A ceases work on package
3) Developer B finds bug in package, fixes it, submits patch, merge
request, etc
4) No response from Developer A

In this case, how do Developer B's contributions get back to the community
if there's an unresponsive maintainer? I think we can do better than
requiring that people google the name of every package they find on ros.org.
Can this second implementation be listed alongside the original on the
wiki? Which repo takes precedence? Do we have standards for when your
package is listed as stale or abandoned? What if there are several packages
with the same name that have a common parent, but different features? What
if people change interfaces? How do we compare different packages with no
common history that do the same thing?

ROS is old enough now that there are a lot of packages, even wg-spawned
packages, whose owners have moved on to other things. I'm talking from
experience on this, since I recently tried to fix what I considered a
serious flaw in a wg-hosted package, only to find that the names listed in
the package manifest are no longer the maintainers and the person listed in
the stack manifest is (understandably) too busy to deal with my  patch. I
find myself blocked, and I could fork it, but this package is currently
distributed with the debian packages and I think creating a new package
with a new name will just lead to confusion and fragmentation.


> I think that Thibault's idea is the best approach we could take right
> now. Giving people the information they need to make an informed
> choice of packages is more useful than trying to kickstart back into
> development a package that does not necessarily need it.
>

I agree that this information should be available right now, and yet, we
can't just leave packages to rot if they're not getting maintained.
Everyone talks about how it's better to have "wild code" out there, but
what's the point if you can't domesticate it, and share it with others?

-j