Re: [ros-users] Hydro Fork Announcement

Forside
Vedhæftede filer:
Indlæg som e-mail
+ (text/plain)
Slet denne besked
Besvar denne besked
Skribent: User discussions
Dato:  
Til: ros-users
Emne: 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