I’m very sorry to try to continue discussion which seems already come to conclusion.
I’m considering “abandoned/orphaned” packages, and if I understand correctly @dirk-thomas conclusions is basically “normal” package maintenance procedure. But “abandoned/orphaned” packages becomes abandoned or orphaned because this “normal” procedure did not work well.
And I understand that there is an opinion like “if no one willing to become maintainer, that packages is not have enough value, so it’s ok to drop it”, But I do not agree on this idea. I believe these packages are still useful, everyone want to use it. but no one can take a responsibility for being maintainer for that. I think this is the problem.
For example I have sent so many hijacking PR last week (sorry for doing that …), mostly for usb camera driver for kinetic. I did released, because ,for me, usb camera is so essential and important, and I believe it worth to include kinetic ros package list, but because it is so general and important that I feel I’m not right person to maintain such a great packages. I guess, these packages did not have been released after 1 years since kinetic release, because everyone feel same way,
So, I like @gbiggs 's idea of having team of maintainer who take care about maintained packages, and from my experience on hijacking release, https://github.com/ros/rosdistro/pull/14890#issue-226190621 , there might be several type of maintenance and if we restrict the role of that team to bloom release, package release, (package migration), then it will not cost to the team members and everyone can continue using existing package to future ros distros.
In conclusion, my proposal for releasing un-maintained packages are;
- contact current maintainer, ask for release
- if we can get answer but find original maintainer lose attention. ask for package transfer to ex.
- if we can not get response, fork that package and gbp to
ros-unmaintaned-maintaner mailing list to package.xml
- someone in the team will release it
Basically, this is as same as @Martin_Guenther 's procedure and the difference between @dirk-thomas “normal” procedures is instead of
add yourself as a maintainer in the package manifest files, we will
add teams as a maintaner. This might be reduce responsibility for people within the mailing list, but that is the aim of making support team for orphaned packages. So if adding mailing list into maintaner tags is allowed, I think this procedure will not violate http://wiki.ros.org/MaintenanceGuide#Claiming_Maintainership, and it seems we had enough people who volunteer to do that (me, @gbiggs and @Martin_Guenther ?)
Minar things :
@Daniel_Stonier 's using
unmaintaned tag and build farm status pages will be nice
- If we create orphaned supporting team group in one organization, do they can get “admin” access to others package repository?
- to reduce team work flow, I think it’s nice to have put all orphaned packages to one organization, so if we add volunteers to existing team, one can working on maintenance work, for same reason we do not create
ros-unmaintanerd-gbp. team member will not want to maintain user management.
- moving to all orphaned packages to
ros-unmaintaned even if admin can add list may overfitting, but once the packages are orphaned, I’m afraid that it is very hard to come back.