Automating cleanup of AUR

[Kevin Morris]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/aur-dev/attachments/20211210/8a60be7b/attachment.sig>