Hi Brett, Thank you a lot for bringing this up. While I am developing the "next-gen" aurweb, I am largely unaware of issues that TU face on live unless they're found in a bug report or communicated to the ML. We do already have some cron scripts that are used for user and package maintenance; looks like we need to produce one here for requests as well. However, before we do so, I would like to iron out a concrete spec for them in terms of timing. Also, "next-gen" aurweb is getting pretty close to release now, so I'd like to put this off until that's released. For the current, more immediate queue issue, I'd like to look into performing a manual cleanup based on our spec as soon as possible, to get these massive request queues out of your guy's heads. We will still need to be sending notifications out about the requests cleaned up by such a cron script, so that we can keep tracking of these actions as much as possible. A few arguments against your current spec: 1. There can be packages which have not been updated for 2 years which are still relevent. 2. Deciding on a number of votes I think is unnecessary. I think we should model these removals based on the state of the package in question + the state of the request (how long the request has existed for). Of course, these ideas are not a tyrannical enforcement of what the spec must be. Please do share any input you guys have. The most important thing here would be ensuring that requests which have been left in an "on-hold" state are not removed sporadically. Perhaps we should introduce a new DB column for requests that allows a TU to mark one as "on-hold" to safeguard against this pruning. We could perhaps prune packages based on how long they have been flagged out of date + how long it's been since they've been modified, with some sort of reasonable lower bound. I'll produce an issue for this to keep track of things in the gitlab repository soon. For now, just tasking immediate concerns. You guys can always drop by #archlinux-aurweb on Libera to chat on IRC about things along these lines. Not that you have to; just letting folks know it's a thing. 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. Regards, Kevin -- Kevin Morris Software Developer Identities: - kevr @ Libera