Re: [ros-users] Hydro Fork Announcement

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: User discussions
Date:  
To: ros-users
Subject: Re: [ros-users] Hydro Fork Announcement
Hi Tully,

On 04.03.2013 22:39, Tully Foote wrote:
> One of the initiatives we plan for Hydro is to keep more up to date
> maintainer information for packages. This is covered in draft REP 137
> [2].


In the pull request you mention the maintainership status has not yet
been added, it is just a comment in the pull request discussion:
[2] https://github.com/ros-infrastructure/rep/pull/27

> We will ask that all packages released into Hydro have clear

maintenance status.

REP137 can only specify a file format to store such information, not the
process being used to gather that information and keep it up to date. As
I mentioned in another post, in the past package maintainers who stopped
maintaining a package often did not bother to announce this to the
community, nor to hand over open issues. I don't think that people will
have a different attitude to a flag in rosdistro.

So is OSRF planning to have a more formal process of maintaining the
maintenance status of packages?
One way could be to regularly query the known package maintainers to
confirm they are still maintaining that package.
Another way could be to check with the version control system and issue
tracker and create a heuristic report of maintenance status. E.g. the
less activity on the version control and the more issues are not dealt
with, the less likely it is that a package is maintained. And vice versa
for allegedly unmaintained packages.

Because without a process that keeps the information up to date, the
information value will quickly deteriorate like the "review" tag in
rosbuild package manifests.

As an alternative, OSRF could do a one-off maintenance survey and just
post it somewhere in the wiki, knowing and accepting that it only
records the situation as of the survey date. That would have the same
value for hydro, but not leave invalid data around for later distributions.

--Thibault