On Thu, Jul 19, 2012 at 10:07 PM, Ken Conley <span dir="ltr"><<a href="mailto:kwc@kwc.org" target="_blank">kwc@kwc.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On Thu, Jul 19, 2012 at 12:49 PM, Jonathan Bohren<br><<a href="mailto:jonathan.bohren@gmail.com" target="_blank">jonathan.bohren@gmail.com</a>> wrote:<br>> On Jul 19, 2012 9:11 PM, "Ken Conley" <<a href="mailto:kwc@kwc.org" target="_blank">kwc@kwc.org</a>> wrote:<br>
>><br>>> If you want to request a feature, it really should be in a ticket<br>>> tracker -- or, even better, a patch should be attached.<br>><br>> Considering the small size of many of the ros package development teams,<br>
> most of the time I submit tickets, bugfixes, feature requests to issue<br>> trackers of projects, it feels like they're going into a black hole.<br><br></div>This was something that KForge (new infrastructure) exacerbated, but<br>
was then meant to help with, but like most infrastructure, takes a lot<br>of love, attention, and care to bring about the final vision -- just<br>to hammer in my point that more infrastructure is not a good thing,<br>IMHO.<br>
</blockquote><div><br></div><div>It's definitely a hard problem, but I feel like we need to do something before things get too broken to fix.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For the issue of patches, my life<br>became a lot easier with stacks hosted on GitHub, where the cognitive<br>load of integrating patches is very low. For stacks not on GitHub,<br>patches come in all different sorts of formats and take a huge amount<br>
of time to test and integrate -- most patches do not come with tests,<br>and I'd estimate the defect rate in patches I've seen at 30-50%.<br></blockquote><div><br></div><div>Yeah, the few cases where I've had good experiences have been through repos hosted on sites where I could fork, patch, and then submit a merge/pull request. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">So, this is a long way of saying that moving more stacks to GitHub is<br>
likely to improve the uptake of patches, though exacerbate the issue<br>of issue trackers. </blockquote><div><br></div><div>Maybe we could make a campaign to get more packages onto repo hosting that have merge/pull request capabilities?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Adding a 'lazy-web' version of feature requests<br>
seems to only compound the issue.<div><div></div></div></blockquote></div><div><br></div>Yeah, I don't think uservoice is a good solution, I sort of want the reverse, where people can more easily submit features, instead of feature requests. I think the feature-request pattern will only work if the community is supplying the feature-responses. This is why I initially asked if we could use <a href="http://answers.ros.org">answers.ros.org</a>. I'm not going to delude myself by saying that I think the maintainers of ROS packages who are also doing research have the time to do the bidding of everyone using their software. I think the pattern should involve users of a package contributing fixes and features back. There are two things that I think set us apart from the majority of open source software projects:<div>
<br></div><div>1) Each independent unit is only maintained by a few people, but is made to inter-operate with code written by thousands of others, so you have very small development teams</div><div>2) At this point at least, people using ROS packages are all also developers writing ROS packages, even if they're not publishing that code, and they actually have the capability to fix bugs in or add features to the small packages they depend on.</div>
<div><br></div><div>I think there needs to be more pushing contributions back to those packages listed in your project's <depend> tags. I just wish there were a better way to facilitate it.</div><div><br></div>
<div>
<div>-- <br><div style="font-family:arial,sans-serif;font-size:13px"><span style>Jonathan Bohren</span></div><div style="font-family:arial,sans-serif;font-size:13px">
<span style>PhD Student</span></div><div style="font-family:arial,sans-serif;font-size:13px"><span style>Dynamical Systems and Control Laboratory</span></div>
<div style="font-family:arial,sans-serif;font-size:13px"><span style>Laboratory for Computational Sensing and Robotics</span></div><div style="font-family:arial,sans-serif;font-size:13px">
<span style>The Johns Hopkins University</span></div><div style="font-family:arial,sans-serif;font-size:13px"><span style><br></span></div><div style="font-family:arial,sans-serif;font-size:13px">
<font style color="#000000"><a href="tel:%28707%29%20520-4736" value="+17075204736" target="_blank">(707) 520-4736</a></font></div><div style="font-family:arial,sans-serif;font-size:13px"><font style color="#000000"><a href="mailto:jbo@jhu.edu" target="_blank">jbo@jhu.edu</a></font></div>
<br>
</div>
</div>