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

[Ken Conley]

I'm definitely in the aggregator camp as well -- from the start, we've
tried to take the assumption of what things will look like in the
future.  Thus, instead of having a single-code repository for our
code, we did multiple repositories, so that assumption wouldn't be
baked into our code.

In the tracker case, we're asking everyone to use the same tracker,
yet at the same time more and more stacks are being maintained by a
greater variety of institutions (on top a system of federated
repositories).

Along the same lines as good integration with source control, my
argument/concern in the past is that I comment my code using issue
tracker numbers so that I can understand why a code block is
particularly nuanced.  It's important not to destroy/confuse this
information.

Ultimately, the use case you described arose because there pages which
do not properly link to the tracker to use... which would suggest a
simpler solution of fixing these link.  In either solution, if there
is no component for a stack in a tracker, there is an error.  Both
solutions rely on maintenance.

 - Ken

On Thu, Dec 8, 2011 at 5:22 PM, Troy Straszheim
<straszheim at willowgarage.com> wrote:
> 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
>
>
>
>
>
>
> _______________________________________________
> Ros-release mailing list
> Ros-release at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-release
>