I only saw automation around this for the first time earlier this year when noticing that a package was multiple versions out of date and tracking it down to a bot (in the pre-LLM sense) on Gitlab for the package that gave a false negative on a version update due to the format of the upstream git tags changing (either they added a `v` to the beginning or removed it, I forget which). My takeaway from that experience is that while automation can be nice, I'm not convinced that the benefits outweigh the potential for bugs like that if it relies on invariants like git tags that are realistically not something that all upstream maintainers are going to be pedantic about keeping standardized.

I understand that having a relatively small number of people maintaining a large number of packages makes it burdensome to manually update everything, but on the other hand, nobody asked me before promoting the AUR package I maintained to the main repos, and I would have been happy to keep doing it indefinitely! I'm not a "official trusted contributor" by any means, but I also know that I would have kept doing what I already did for years in exactly the same way without any issues, so I can't help but feel a bit like like a known good with hypothetical risks was thrown away for something that will produce at best the same results with less severe but more concrete risks. I wish I had a solution for not getting stuck at that local optimum, but incidents like the one in the article will only make it more of an uphill battle.

(edit: to clarify, I'm not proposing that the package should have been left in the AUR, but that I wish there were a way for them to have just let me keep maintaining it as an "official" package. Maybe something like the kernel model where someone trusted could vet the PKGBUILD updates I do and decide whether to merge them or not rather than doing the same but with a bot, and then maybe not noticing that the bot is silently failing...)