You've spoken the words inside my mind. I create this bot since sometimes I just don't even have time to do a simple version bump. If someone feels that they can do better and would like to maintain any of my package, please comment under that package and I'll add you as a co-maintainer to replace the auto update bot. 在2023年04月14 01时09分，"tobi"<tobi@tobi-wan-kenobi.at>写道： Hello everyone, I rarely ever join these discussions, so please bear with me, should I breach the code of conduct somehow. (And yes, I am fully aware I will live to regret this mail) Quoting Polarian <polarian@polarian.dev>:
Hello,
I'd say automation is fine, if it opened a pull request which can be reviewed and tested. But blindly pushing new versions to the AUR is for me a no-go.
Yes, but the main part of this thread was not to discuss automation, that is not the issue. The issue is people want fully automated maintaining of AUR packages, which is just not possible. And this entire thread has been trying to prove CI/CD is intelligent enough to spot ALL the errors which could occur during a build and say that CI/CD can check them all, which is just not possible.
I disagree here. Nobody tried to make the point that CI/CD can spot all errors. But I assume and hope your point is also not that a human can do so. I know *I* cannot. Automation and CI/CD is an excellent choice for everything that *can* be automated. Your example of "does it compile on Arch"? 10/10 for automation. Reproducible and a binary result. Why not automate that check?
I think people are forgetting that as a Maintainer you are meant to look into each update, read the change logs, check if there is any incompatibilities, patch out anything which is non-free (if possible) or patch any issues with the source which might not compile on Arch Linux for whatever reason, check new dependencies, check if dependencies have been removed, check if the compile procedure has changed, and thus the PKGBUILD will need rewriting, the list goes on.
Sure a PR to bump the release is always nice, but it should be checked against all the things I have named above, and then merged, then you push it manually.
If you don't have the time for the above? try maintaining less packages, or try finding more time, there is no cheat code to maintaining packages.
Is that an official statement, or your personal opinion? It sounds opinionated to me. I had a quick look at the AUR submission guidelines, but was unable to find anything on automation or required pre-update checks, at all. If you can point me to relevant documentation, I'd appreciate that a lot. Also, I think it's accepted that the AUR has varying degrees of quality and the requirements are less strict than for core repositories. Is that a good thing? Depends, if you want a large package base, then yes. If you want a staging area for packages that *maybe* eventually get migrated into a core repo, also yes. If you want packages of the highest quality, then no. But IMHO, having a "vetting area" for packages makes tons of sense. Should quality be high in the AUR as well? Ideally yes, but welcome to the real world. The AUR packages are maintained by volunteers, who are not paid and who have a life outside the AUR (hopefully). I have the highest respect for people that maintain hundred or thousands of packages for the benefit of others, and if automation makes their lives easier - more power to them! I'd rather have a package that breaks occasionally and needs manual intervention *then*, rather than not having that package in AUR at all. But then: Take that with a grain of salt, it's personal opinion, not canon. Really, all of this is about *tradeoffs*. If I have a fully automated CI/CD pipeline for my AUR package, and it breaks once every two years, is that good enough? In my book, absolutely, but your milage may vary, and you are welcome to maintain your AUR packages differently. I am maintaining an AUR package for which I am also the main contributor, for example. I know when the dependencies change and when the license changes, so for me, 100% automation makes sense (my CI/CD pipeline catches build errors and has a decent test coverage, of course). Other maintainers have different situations and requirements. This finally is my main point: There is no simple "this is the right way to do it, and everything else is wrong". Rather, a lot of those decisions are situative and subjective. I don't believe in simple answers and "one size fits all" solutions in software engineering. There's just various degrees of broken-ness :)
In simple terms, automation is good, using it carelessly is bad.
Well even carelessly it isn't bad, someone should always check whatever CI/CD task which is executed. I feel developers rely too much on CI/CD these days and want to write a script to do everything, without realising that their intervention is still needed.
How can the Arch community educate the aur maintainers to not push untested PKGBUILDs?
You cant!
As I highlighted in a earlier post, the AUR is digging through PKGBUILDs until you find a decent one. TUs don't have all day to go through all packages and check whether they are sticking to the packaging guidelines. As far as I am aware, they mainly focus on ensuring no illegal packages are on the AUR, and no malicious packages, along with dealing with disputes about who should maintain what.
If you feel that a package is poorly maintained, ask for co-maintainer or submit a patch to fix whatever it is.
I do feel the packaging guidelines should reflect what both Anthraxx and Jelle has recommended. And I kindly ask for the sake of the people who use fully automated packages to please stop, you do not need to update the package within 2 hours of it being flagged out of date, you have upwards of 6 months until the package is orphaned, there is no reason to not be reviewing your packages before committing.
My 2c: I will only switch from an automated workflow to a manual one if I see benefits to it. For my personal use cases, the automation is much less error prone than I am, and much more reliable (it never gets tired of checking the same old corner cases). Asking for 100% reliability is IMHO not realistic, in any of those scenarios. Thank you very much for reading until here, And if we shadows have offended, think but this, and all is mended: That you have all but slumbered here, while these visions did appear.
Remember to always check a package before you build it, hopefully the TUs find and remove most of the malicious packages, but you better be safe than sorry.
Have a good evening, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev