> 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 think Geoff captures part of the argument nicely with this analogy,
and I mostly agree with him that the second option is better.
However, it's a bit more complicated, since the linux ecosystem
consists (mostly) of a bunch of applications.  If one of them gets
orphaned, then it doesn't affect (m)any of the others.  If I use one
that stops working, or doesn't have bugs fixed, then I can move to
another application that does the same thing more-or-less with
impunity.  ROS, on the other hand, is an ecosystem of components that
are inherently more inter-related.  If something critical is orphaned,
it can cause ripple problems through your entire system.  A recent
example of this might be the kinect drivers in fuerte.  Also, for many
of the important packages, there is no (viable) alternative.

> 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.

I also agree with this, but I also think that some larger-scale
ordering is needed.  Some way to see which packages are well-used,
currently maintained, looking for help, etc would be very useful, I
think.

-- Bill