[ros-users] Uservoice-like Suggestions Page

[Ken Conley]

On Thu, Jul 19, 2012 at 12:49 PM, Jonathan Bohren
<jonathan.bohren at gmail.com> wrote:
> On Jul 19, 2012 9:11 PM, "Ken Conley" <kwc at 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.

At the heart of it, good bug trackers are integrated with the
codebase.  If the  codebase is distributed, it becomes very difficult
to have a non-distributed bug tracking system.

The separation of ROS stacks has helped maintainability and made it
easier to receive patches, so I think the benefit is net positive, but
it has created this other burden.  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%.

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.  Adding a 'lazy-web' version of feature requests
seems to only compound the issue.

 - Ken


>
> I've even gone to submit a bugfix (with an attached patch) on a project's
> issue tracker once, only to find that someone else had submitted a similar
> fix half a year earlier that was never dealt with.
>
> On the other side of it, when I was going through a very busy period, I
> didn't put much time into maintaining some ros software that I had written,
> myself.
>
> I think the hyperdistributed nature of the ros ecosystem really needs
> something more than a hundred independent issue trackers. I understand that
> distributed version control can help, but if everyone just forks a project
> when they feel like their issues/tickets aren't getting addressed in a
> timely manner, then it's just going to lead to severe fragmentation. And
> even worse, if all the forks of a given stack aren't listed on ros.org, only
> the repo for the stale one will end up getting used by others, and the
> efforts will have been wasted.
>
> Does anyone else feel like we need some better way to coordinate these
> things to prevent code death or such fragmentation from happening to the ros
> community? My recent experiences have made me concerned for the future
> health of the ecosystem.
>
> -j
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>