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

Tully Foote tfoote at willowgarage.com
Fri Dec 9 02:14:00 UTC 2011


I definitely agree that this is becoming a challenge to manage and we
should make sure it is easy to use.

However, I believe that the one tracker system is extremely imposing to
external developers and near impossible already.  And as we work toward
making external library integration easier this goes the opposite
direction.  And as we're approaching the point that external libraries can
simply add "ROS Compatability" with a few metadata files we can't tell them
to use our tracker.  And if we have one main one and many small ones, we
still have the same problem.

The best working solution for this type of thing I can see is Launchpad,
but it's more of a metatracker/integration tracker.  Take this ticket for
example: https://bugs.launchpad.net/xorg-server/+bug/278078 It has links to
two upstream tickets, flags multiple components, and has tags for which
releases it affects.  But there's no automatic connection between any of
those bugs, humans did it all, it's just another tracker.

I think that we should identify the primary use cases and make sure that
they're well documented, and make it part of the release review process.

The three use cases I see as the biggest are as follows with the easiest
fixes:

Where do I file a ticket?
Solution: Fix links on stack pages.  (Improve them for external tracker
support; external repos often need to hard code the links.)

What tickets are open against this component?
Solution 1: Fix links on stack pages (Improve them for external tracker
support; external repos often need to hard code the links.)

What tickets are assigned to me?
Solution: For the next release of kforge there is going to be a personal
aggregator for all your tickets.  It would seem that this infrastructure
could be extended to aggregate over customizable external repos.  Just give
kforge the url, tracker type, and your username to query the databases.

If we wanted to make this more formal we could add the metadata to the
released files, but I expect that the accuracy would be even worse than
that of the wiki links, and couldn't be updated if anything changed.

Tully

On Thu, Dec 8, 2011 at 5:56 PM, Ken Conley <kwc at willowgarage.com> wrote:

> On Thu, Dec 8, 2011 at 6:18 PM, Brian Gerkey <gerkey at willowgarage.com>
> wrote:
> > On Thu, Dec 8, 2011 at 3:57 PM, Ken Conley <kwc at willowgarage.com> wrote:
> >> I'm definitely in the aggregator camp as well
> >
> > I could be convinced to have an aggregator instead of a unified
> > tracker.  But I'd hate to have to build and maintain it.  Is there a
> > good multi-tracker aggregator out there?
>
> Not that I'm aware of, but I believe there is at least multi-Trac
> aggregators, though aggregators don't solve the 'where do I file
> this?' ticket problem, just the 'what tickets do I have?' problem.
>
>  - Ken
>
> >
> >        brian.
> _______________________________________________
> Ros-release mailing list
> Ros-release at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-release
>



-- 
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20111208/2c82d708/attachment-0009.html>


More information about the Ros-release mailing list