[aur-general] TU application for sudoforge

[Ben Denhartog]

On Fri, Feb 18, 2022, at 02:51, David Runge wrote:
> On 2022-01-29 15:27:44 (-0700), Ben Denhartog via aur-general wrote:
>> - crictl
>> - critest
>
> Here we can use some effort to upstream fixes so that it is easier to
> build.

I'm happy to help with that.

>> - kubectl
>
> This comes at the cost of maintaining the kubernetes pkgbase.
> I would be interested to hear your thoughts on improvements and or
> post-build test scenarios for this (that we can hand to the testers).

Kubernetes has a pretty robust test suite. To better understand how to improve our post-build test scenarios, I'd want to take a look at what we're currently doing. Personally, new versions of Kubernetes are tested in my pipeline as such before upgrading:

- A cluster-in-clu
- The new version is deployed
- Upstream's E2E test suite is ran (kubetest2). This tests API conformance.
- My own tests specific to my environment, which is used to test basic workflows like deploying a dummy application and routing to it, etc.

This is robust, but comes at a cost (both financial cost of the infra and the opportunity cost of the time spent building this out). Whether or not doing this within the Arch Linux ecosystem makes sense is something we'd need to discuss.

>> - podman
>
> This is an interesting one, especially in regards to e.g.
> containers-common, which is still a bit weird and only recently we have
> found out how it is "supposed to be packaged".
> Do you have any improvement suggestions for it and/or test scenarios
> that you could think of?

Well, we could start by running upstream's tests :)

I agree that the separation they have for documentation and libraries that are shared into the "common" repository is... different. Heavy reusability is why I prefer monorepos, so perhaps I'm biased against this separation.

>> - zsa-wally-cli
>
> If you have improvement suggestions for this in regards to providing
> fixes for upstream, that would be very much appreciated.
> Upstream unfortunately does not use their issue tracker anymore and
> expects people to send mails.
> They are unfortunately also easily offended :S

What sort of issues are you encountering? I haven't packaged this myself, but from the PKGBUILD, it doesn't seem like there's complexity to it (or the graphical app) that require upstream patches.

> What comes to mind here (apart from the packager workflows) is e.g. our
> installation artifact release process and also our CI integration with
> archlinux-keyring to detect soon expired keys as soon as possible, to
> list a few that are rather pressing and/or fall on our feet from time to
> time.
> A good place to idle for that would be #archlinux-releng and
> #archlinux-projects! :)

Both of those sound like the sort of projects I'd like to look at and work to improve. I'll follow up with you in IRC.

-- 
  Ben Denhartog
  ben at sudoforge.com