On 2021-12-11 07:10 +0000 George Rawlinson via aur-dev wrote:
On 21-12-10 19:42, Kevin Morris via aur-dev wrote:
Alright. Now, please let me know what you guys think are some good ideas for pruning out requests and ancient packages that would not interrupt expected workflows or "accidently" remove packages.
There are a lot of things that can be automated. Here's my wish list:
1. Cron - Automatically delete packages that have been orphaned for longer than x months. I think 3-6 months is reasonable. Popular packages tend to be maintained very quickly after they have been orphaned so I don't think this is too aggressive. Not to mention that the git repositories are still intact after deletion so if anyone wishes to re-add a previously deleted package, the history is there.
2. Cron - Automatically orphan packages that have been flagged out of date for longer than x months. I would think a month or two is a reasonable length of time for maintainers to either unflag the package or actually maintain the package.
3. Cron - Related to #1. Before removing the packages from the AUR, an automated email can be sent to aur-general with a list of packages about to be deleted and if anyone wants to maintain these, they're up for grabs. I think weekly would be a bit much, so maybe monthly?
4. I want a pony.
There are currently over 72,000 packages, and only 60-odd Trusted Users ^W ^W Package Maintainers. Anything that eliminates time spent pruning the AUR is a welcome addition.
-- George Rawlinson
I suggest that any automatic removal of orphans after x months be combined with 2 additional conditions: last download y months ago and upstream is gone. If it's orphaned, unused and upstream is gone, it's clearly dead. We should not automatically remove packages that are still in use, and if upstream still exists than the package may be picked up again. Those packages can still be flagged manually by users and either purged automatically after some fixed time in the request queue, or tagged there to indicate that they can be purged without further investigation. Expanding on that, it would be very useful if the request dashboard provided relevant package details directly, such as last update, orphan age, and download statistics. Maybe even a timestamp of the maintainer's last activity on the AUR. Automatically orphaning packages after x months of being out-of-date is a good idea. It may even be a good idea to mark a maintainer's account as inactive whenever a package is orphaned so that orphan requests for other packages solely owned by the same maintainer can be accepted immediately. The maintainer would be marked as active again following any AUR activity. The package page should then indicate if the maintainer is considered inactive and that an orphan request would be accepted automatically. Inactive maintainers can be automatically removed from all packages after x months of inactivity, but x should be 6 to 12 months imo. Any rules for automatically accepting orphan requests should also apply to co-maintainer requests, perhaps with reduced time limits. I like the idea of announcing automatically removals as a last-chance call for maintainers. A notification to aur-general might be useful, but I would prefer a dedicate dashboard on the AUR itself visible to everyone where users could quickly adopt the packages directly. If you want to have a little fun with it, add a big purge countdown timer at the top and a pacman pill-eating animation to clear them when the time runs out. I'm tempted to go off on a tangent exploring the possibilities of federated package management for the AUR but I've probably bikeshedded enough already so I'll stop here. Regards, Xyne