<div>I definitely agree that this is becoming a challenge to manage and we should make sure it is easy to use. </div><div><br></div><div>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. </div>
<div><br></div><div>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: <a href="https://bugs.launchpad.net/xorg-server/+bug/278078">https://bugs.launchpad.net/xorg-server/+bug/278078</a> 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. </div>
<div><br></div><div>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. </div><div><br></div><div>The three use cases I see as the biggest are as follows with the easiest fixes:</div>
<div><br></div><div>Where do I file a ticket? </div><div>Solution: Fix links on stack pages. (Improve them for external tracker support; external repos often need to hard code the links.)</div><div><br></div><div>What tickets are open against this component?</div>
<div>Solution 1: Fix links on stack pages (Improve them for external tracker support; external repos often need to hard code the links.)</div><div><br></div><div>What tickets are assigned to me?</div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>Tully</div><br><div class="gmail_quote">On Thu, Dec 8, 2011 at 5:56 PM, Ken Conley <span dir="ltr"><<a href="mailto:kwc@willowgarage.com">kwc@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Dec 8, 2011 at 6:18 PM, Brian Gerkey <<a href="mailto:gerkey@willowgarage.com">gerkey@willowgarage.com</a>> wrote:<br>
> On Thu, Dec 8, 2011 at 3:57 PM, Ken Conley <<a href="mailto:kwc@willowgarage.com">kwc@willowgarage.com</a>> wrote:<br>
>> I'm definitely in the aggregator camp as well<br>
><br>
> I could be convinced to have an aggregator instead of a unified<br>
> tracker. But I'd hate to have to build and maintain it. Is there a<br>
> good multi-tracker aggregator out there?<br>
<br>
</div>Not that I'm aware of, but I believe there is at least multi-Trac<br>
aggregators, though aggregators don't solve the 'where do I file<br>
this?' ticket problem, just the 'what tickets do I have?' problem.<br>
<font color="#888888"><br>
- Ken<br>
</font><div><div></div><div class="h5"><br>
><br>
> brian.<br>
_______________________________________________<br>
Ros-release mailing list<br>
<a href="mailto:Ros-release@code.ros.org">Ros-release@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-release" target="_blank">https://code.ros.org/mailman/listinfo/ros-release</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tully Foote<br>Systems Engineer<br>Willow Garage, Inc.<br><a href="mailto:tfoote@willowgarage.com">tfoote@willowgarage.com</a><br>(650) 475-2827<br>