On 07/20/2012 09:05 AM, Jonathan Bohren wrote:
> 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.
A solution would be for you to get commit access to the stack.
That would require the stack maintainer to trust that you either
made sure your patch does not cause breakage, or that you will
put in time to unbreak / revert if breakage happens.

Another solution would be for the stack to get another/an additional
maintainer that has more time.

What I suggest is an objective way of showing which
stacks need more maintainers and which patch
contributors can be reasonably trusted, as the data
can show how much people have been involved with ROS,
and how much of a burden stack maintainers carry.

So both solutions could become more likely, that you get
the necessary trust at a glance to the data of your activities,
and/or that the stack you talk about gets an additional/new
maintainer.

By the way, collecting the data from all trac systems
would also allow using that data for creating polls. As
in a small web application can allow users to enter ticket
IDs for tickets that exist in individual trac systems to
raise attention. This would also encourage people to
use trac rather than ansers.ros to raise issues.