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