The decision between stack vs package is a tough one. It depends on how
many features are desired and if there are external dependencies.
In general fewer stacks are better, but if combining things into an existing
stack is going to bring in a large number of new dependencies or rosdeps
into a stack a judgement call need to be made as to whether it's better to
incur the cost of managing a separate stack, or cause all users of that
stack to require the additional dependencies.
Thus I'd suggest proposing it as (a) package(s) to go into another stack.
And when reviewed, if it makes more sense to make it a stack of its own
then so be it.
Tully
On Fri, May 21, 2010 at 8:03 PM, Jack O'Quin <
jack.oquin@gmail.com> wrote:
> On Fri, May 21, 2010 at 9:35 PM, Tully Foote <tfoote@willowgarage.com>
> wrote:
>
> > With regards to a location of a potential GPS message within the ROS
> package
> > ecosystem, as the maintainer of common_msgs this seems like a strong
> > candidate for inclusion in the sensor_msgs package.
>
> Good idea. I hadn't thought of that. I was imagining a new package
> defining both the messages and some utility functions.
>
> Putting just the messages in sensor_msgs is better. There might end up
> being two or three messages, depending on how people decide to
> structure it.
>
> > As for the library components doing a package proposal for gps_common
> would
> > be a good idea.
>
> I just realized that Ken Tossell already has a gps_common package in
> the umd-ros-pkg (University of Maryland). Looks like it only has a
> message definition right now.
>
> Whether we call it that or something similar, should it be a separate
> stack or part of some existing one?
> --
> joq
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
--
Tully Foote
Systems Engineer
Willow Garage, Inc.
tfoote@willowgarage.com
(650) 475-2827
(text/plain)