[ros-users] Uservoice-like Suggestions Page

Jonathan Bohren jonathan.bohren at gmail.com
Fri Jul 20 11:11:39 UTC 2012


On Fri, Jul 20, 2012 at 10:57 AM, Thibault Kruse <kruset at in.tum.de> wrote:

> On 07/20/2012 09:05 AM, Jonathan Bohren wrote:
>
>> I'm talking from experience on this, since I recently tried to fix what I
>> considered a serious flaw in a wg-hosted package, only to find that the
>> names listed in the package manifest are no longer the maintainers and the
>> person listed in the stack manifest is (understandably) too busy to deal
>> with my  patch. I find myself blocked, and I could fork it, but this
>> package is currently distributed with the debian packages and I think
>> creating a new package with a new name will just lead to confusion and
>> fragmentation.
>>
> A solution would be for you to get commit access to the stack.
> That would require the stack maintainer to trust that you either
> made sure your patch does not cause breakage, or that you will
> put in time to unbreak / revert if breakage happens.
>

Yes, and in another instance this is what I did, but even then, it was in
their experimental branch, which is still taking a long time to get merged
into their distribution trunk.


> Another solution would be for the stack to get another/an additional
> maintainer that has more time.
>

Yeah, and I think your analytics are a first step to allowing us to make
decisions like this.

------------------------------------------------------------------------------------------------------------

On Fri, Jul 20, 2012 at 12:05 PM, Thomas Moulard <thomas.moulard at gmail.com>
 wrote:
>
> Please remind yourself one thing: we are *researchers*, not engineers.
> We are not paid to maintain code. Keeping a package up-to-date in ROS
> is something which is extremely time consuming and need high proficiency
> in a lot of technical domains.
>

> To sum up, don't try to make people maintaing their softs on the long
> term, you'll
> be disappointed :)
>

Absolutely. Hence why I harbor no anger or frustration at the maintainers
of the stacks that I've tried to contribute to, but rather that the
community doesn't have a better process for this.


> What we should *NOT* do:
> - remove obsolete packages from the wiki or make it hard to register
> software in it.
>

Yeah, this would be a step backwards.


> As for the repository rights, we don't need them. Open source packages
> have been forked for 30 years of *NIX history, IMHO this is the only
> practical solution.
> Especially now, with Git and GitHub, it has become so easy!
>

Right, so maybe if a package gets forked and indexed, the forks can be
listed on that package's ROS wiki page.


> - close as much pages as possible to help people find reliable information.
> - consolidate the current websites into one coherent entity.
> - find a way to aggregate tickets from other systems such as GitHub
> - encourage people to add their stack to the wiki: we need to keep a
> trace of all the developments to avoid duplicating efforts
>
> - create different stack "quality levels":
> -- -1: deprecated
> --  0: experimental / work in progress
> --  1: released
> --  2: core
> The information is already here, in the manifest file, but we need to
> motivate people
> to make releases and go through the Q&A process.
>

I'd think, in addition to "deprecated" maybe labels "abandoned", "stale",
and "inactive". The code might still work, and there's no reason why
someone should avoid it, but nobody is actively maintaining it.

- "abandoned" : the original author has explicitly left the package up to
be maintained by someone else
- "stale" : there are outstanding tickets in the project's issue tracker
that have not been dealt with
- "inactive" : no activity, but no outstanding tickets, either

 ------------------------------------------------------------------------------------------------------------

On Fri, Jul 20, 2012 at 12:48 PM, Michael Carroll <carroll.michael at gmail.com
> wrote:

> The Stack Version Policy (http://ros.org/wiki/StackVersionPolicy)  shows
> that stacks should have version numbers < 1.0 to indicate
> development/alpha/beta and > 1.0 to indicate stable.
>
> Of course, this is only required to release a stack, not to get it
> indexed, so not every stack has it.  Perhaps making this a required tag to
> be indexed?  Or if not required, we could make it strongly encouraged?
>  Also, the version number is not very visible in the wiki documentation, so
> maybe increasing visibility on this would be worthwhile.
>

But I'd like to reiterate what Thomas said above, and not a lot of people
either have the resources to properly release a stack, so I like the idea
of a simpler flag system. The key to this is that it needs to be automated.
This whole problem is predicated on people not having enough time, so we
shouldn't expect them to maintain flags. I've gone through the stack
release process at Willow, and going through this process is very
time-consuming. Even once a stack has been released, though, it can still
get abandoned or get stale later on.

 ------------------------------------------------------------------------------------------------------------

On Fri, Jul 20, 2012 at 12:15 PM, Thibault Kruse <kruset at in.tum.de> wrote:
>
> I personally like using websites like Ohloh and freecode (aka
> freshmeat.net)
> https://freecode.com/
> where the community can go wild in maintaining meta information, rating
> and
> commenting, and where there are also some automated reports.
>
> Both ohloh and freecode allow the community to add projects, so
> there is no need to wait for stack maintainers to do it if you feel a
> stack should be tracked online. The "ros" tag is unused in both ohloh
> and freecode, so for now we can use that tag to have some kind of
> subspace.
>

This is an interesting way to get started. Maybe we can get in touch with
the freecode guys and see if they have an API that we could easily
integrate with the ROS wiki?

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20120720/b9c25dad/attachment-0004.html>


More information about the ros-users mailing list