> 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 wrote: > On Thu, Jul 19, 2012 at 10:07 PM, Ken Conley wrote: > >> On Thu, Jul 19, 2012 at 12:49 PM, Jonathan Bohren >> wrote: >> > On Jul 19, 2012 9:11 PM, "Ken Conley" 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 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 > > (707) 520-4736 > jbo@jhu.edu > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > >