> Maybe we could make a campaign to get more packages onto repo hosting that have merge/pull request capabilities? 
+1 to that. We need to let ROS developers know about this.

Alex Bravo

On Thu, Jul 19, 2012 at 1:59 PM, Jonathan Bohren <jonathan.bohren@gmail.com> wrote:
On Thu, Jul 19, 2012 at 10:07 PM, Ken Conley <kwc@kwc.org> wrote:
On Thu, Jul 19, 2012 at 12:49 PM, Jonathan Bohren
<jonathan.bohren@gmail.com> wrote:
> On Jul 19, 2012 9:11 PM, "Ken Conley" <kwc@kwc.org> wrote:
>>
>> If you want to request a feature, it really should be in a ticket
>> tracker -- or, even better, a patch should be attached.
>
> Considering the small size of many of the ros package development teams,
> most of the time I submit tickets, bugfixes, feature requests to issue
> trackers of projects, it feels like they're going into a black hole.

This was something that KForge (new infrastructure) exacerbated, but
was then meant to help with, but like most infrastructure, takes a lot
of love, attention, and care to bring about the final vision -- just
to hammer in my point that more infrastructure is not a good thing,
IMHO.

It's definitely a hard problem, but I feel like we need to do something before things get too broken to fix.
 
For the issue of patches, my life
became a lot easier with stacks hosted on GitHub, where the cognitive
load of integrating patches is very low.  For stacks not on GitHub,
patches come in all different sorts of formats and take a huge amount
of time to test and integrate -- most patches do not come with tests,
and I'd estimate the defect rate in patches I've seen at 30-50%.

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. 
 
So, this is a long way of saying that moving more stacks to GitHub is
likely to improve the uptake of patches, though exacerbate the issue
of issue trackers.  

Maybe we could make a campaign to get more packages onto repo hosting that have merge/pull request capabilities?
 
Adding a 'lazy-web' version of feature requests
seems to only compound the issue.

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 answers.ros.org. 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:

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
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.

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.

--
Jonathan Bohren
PhD Student
Dynamical Systems and Control Laboratory
Laboratory for Computational Sensing and Robotics
The Johns Hopkins University



_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users