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

[Troy Straszheim]

On Thu, Dec 8, 2011 at 2:35 PM, Brian Gerkey <gerkey at willowgarage.com>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?
>

Well intentioned for sure, but I'm very negative on this idea because I
think it is doomed from the outset.

Good issue trackers have good integration with source control, email, etc.
 I can for instance commit to github with a message "closes #13" and have
the message automatically closed.  If I file a bug and someone comments on
it, I get an email from a magic address... if I reply to that mail, my
response magically appears in the log.   If I refer to a commit in this
email, the comment that magically appears in the tracker has a magic link.
 Any commits containing the string "#47" appear in the log for issue 47.
For that matter, there are android apps that make github issues accessible
on my phone.  I could go on.   Other systems probably have similar but
different features that work for others.

So different bugtrackers work well for different workflows and VCS systems.
 I'd rather fix the difficulty of figuring out "where do I file a bug on X"
or "what outstanding bugs are there on Y", assuming I don't know where X
and Y's source/trackers are, by consulting an aggregator of some kind,
rather than creating One Tracker which some will ignore anyway.  That
they'll ignore it anyway isn't fixable (one can't run around and turn off
bug trackers one doesn't have admin rights to).  Others will grudgingly use
the One Tracker despite the fact that it makes their workflow less
efficient.

It makes the process of starting to track bugs on a new project more
difficult as well.  If I'm doing some small-group development and want to
keep track of some issues, do I have to get a slot on the One Tracker
before I have any idea whether somebody is going to want to see my tickets
in a central area?   If not, then this business of importing tickets from
assorted bugtrackers is going to be ongoing.  Sounds like an aggregator...

If an aggregator exists, and I don't see any bugs for X there, I can verify
that X is known to the aggregator, and if it is, I know there are no bugs
for X (provided the aggregator isn't utterly broken).  If it isn't known, I
can fix this by adding X to the aggregator.

If there is but One Tracker, and I see no bugs for X but am skeptical, I
have to go trawling around for possible existing bugtrackers for X anyway.
 So you might try to assist this trawling process... by building an
aggregator...

-t
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20111208/64df4827/attachment-0009.html>