Well, I first voted
Leave all entries as they are since I used to search
ccr for programs I need. Changed my mind 'cause I often found promising offers that did not install, for dependency problems. Since a package I can’t install is worthless for me I changed my mind an selected
Other action. I would suggest to delete all packages that can’t be installed anymore. Since I suppose that checking this is quite cumbersome and thus may not be viable my second choice would be to
Leave all entries as they are. Thus users would have the chance to get the package installed by editing the PKGBUILD file.
Well, I first voted
Here’s my “Other” vote.
The first action I vote for is to give a notice to maintainers of packages which haven’t been updated and ask them to do an update (even if it’s just to bump the packaging version like
1.2.3-1 → 1.2.3-2). If there is no update after some time, then mark it as orphaned.
The next steps depend on answers to these questions.
Instead of outright deleting a package, can it be “archived” somewhere so it doesn’t show up in normal search results but can still be found with an advanced search? Even linking to something off-site would be useful.
Can you see how recently a package has been voted for? I imagine recent voters could be recruited as maintainers.
Can a script do a “fake update” on all orphaned packages to give users a warning of impending removal?
Here’s how my vote continues depending on which of these have “yes” answers:
- If packages can be archived, then archive all packages which haven’t had activity (updates, votes, comments, new maintainers, etc) in over a year.
Otherwise only delete packages which are “unpopular” based on number of votes. (See below for some popularity stats.) This would get rid of the bulk of unmaintained packages while leaving wanted orphans around for future maintainers to pick up easily.
- If you can see when votes were made, then only archive/remove packages which haven’t been voted for in over a year.
Otherwise, please consider doing a bulk vote reset and seeing how many votes there are after another year.
- If you can do automatic “fake updates” to give orphan warnings, then do so as soon as a package has been orphaned, and wait at least 2 months before removing orphaned packages. If no one volunteers to maintain a package or asks someone to help them after 2 months, then they probably don’t care about it enough.
If you can’t do “fake updates” like that, then please consider updating the
chaserpackage to give a more general warning with a link to an appropriate forum thread that explains what’s going. In that case, wait more like 3-4 months before archiving/removing orphaned packages.
For reference, here are some popularity statistics about the 2413 orphaned packages (45.6% of all packages) currently in the CCR.