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