On 20 July 2012 04:49, Jonathan Bohren wrote: > Does anyone else feel like we need some better way to coordinate these > things to prevent code death or such fragmentation from happening to the ros > community? My recent experiences have made me concerned for the future > health of the ecosystem. I don't necessarily agree with this. I think the problem described is the same problem faced by Linux in general (the operating system, not the kernel). There are thousands of abandoned software packages available for Linux, a large proportion of which are available through various distributions' package managers despite being orphaned. I think the approach to this issue can be decided based on what ROS's goal actually is: Is ROS meant to be a single, cohesive software project with distributed development teams working on various parts of it? In this case, I think that centralised ticket management makes sense - but it also requires someone to sit at the centre and maintain that infrastructure. 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. I personally think ROS is, or at least should be, the second option, and we should look at how various distros manage these problems. For example, Gentoo removes unmaintained packages from its repository and relies on them being provided by overlays managed by the people who care about those packages. Using a package from an overlay tells you you're not getting the same level of support. Debian/Ubuntu's multiverse and PPAs could be seen as doing something similar. 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 often use Wikipedia's "Last release date" information when choosing amongst alternatives for a piece of software. Geoff