Re: [Ros-release] how about a single issue tracker?

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
Delete this message
Reply to this message
Author: Patrick Mihelich
Date:  
To: Brian Gerkey
CC: ros-release
Subject: Re: [Ros-release] how about a single issue tracker?
+1

On Thu, Dec 8, 2011 at 2:35 PM, Brian Gerkey <>wrote:

> hi maintainers,
>
> We have many issue trackers for ROS software. It all started with the
> way that we originally structured the code. We wanted a separation
> between the plumbing (the 'ros' repo), the generic capabilities
> ('ros-pkg') and the Willow/PR2-specific capabilities ('wg-ros-pkg').
> As is commonly done, we created a Trac for each repo. Now, with code
> stored in approximately 100 repositories, there are trackers at
> code.ros.org, kforge.ros.org, github, googlecode, and pretty much
> every other hosting site.
>
> This situation is confusing to users. E.g., if I find a bug in tf,
> should I file a ticket at the 'ros-pkg' Trac, using the 'geometry'
> component (which is what the geometry wiki page recommends) or should
> I use the kforge 'geometry' Trac (because I know that that's where the
> code actually lives), which has open tickets in it? How about
> graph_mapping? The wiki page (http://ros.org/wiki/graph_mapping)
> doesn't have a "report bugs" link. The code is in 'ros-pkg', so maybe
> I should use the 'ros-pkg' Trac, but then there's no 'graph_mapping'
> component in that Trac. It's also inconvenient for developers; I need
> to query and aggregate from several different trackers to get a
> picture of my open tickets.
>
> Also, each tracker is configured differently from the next, and
> different sets of credentials are required to file bugs against
> different parts of the ecosystem.
>
> Enough motivation; you get the point. Federated development makes
> sense; but federated bug-tracking, I think, does not.
>
> A modest proposal: we create a single unified issue tracker for ROS
> software. Rough draft:
> * agree on a tracker system (would be a minor holy war, but not insoluble)
> * host it at ros.org
> * authenticate via OpenID (like ROS Answers)
> * create a component/module for each released stack
> * create components/modules for unreleased stacks as requested
> * change (simplify) the wiki to offer a single "report bugs" link that
> can appear on every page
> * wherever feasible, move open tickets from legacy trackers into the new
> one
>
> Thoughts?
>
>        brian.
> _______________________________________________
> Ros-release mailing list
> 
> https://code.ros.org/mailman/listinfo/ros-release

>