[aur-general] TU application - artafinde

[Morten Linderud]

On Sun, Oct 31, 2021 at 06:24:51PM +0000, Leonidas Spyropoulos via aur-general wrote:
> Hello,

Yo!

Good luck with your application :) Some preliminary thoughts.

> I'd also be interesting in maintaining some Community packages which
> are orphan or co-maintain some:
> orphans:
> - elasticsearch

This isn't as much of an orphan as there is a question what to do with the
elasticsearch ecosystem in Arch. With the relicensing and subsequent release of
opensearch what are you plans for this package? This also applies to the beat
packages and auxiliary packages to the ELK stack.

> packages I use and interested in {co-}maintaining:
> - ansible
> - aurpublish
> - aws-cli
> - ccache
> - cpupower
> - docker
> - docker-compose
> - go

I'd rather not have a co-maintainer for go unless they want to take some
responsibility for the ecosystem and packaging standards as well. It's quite a
bit of work and just updating Go is the simple part of it. So what are you
thoughts here?

> - gradle
> - kotlin
> - kubectl
> - lrzip
> - neomutt (used to be co-maintainer in aur)
> - notmuch
> - profile-sync-daemon
> - alot
> - android-file-transder
> - android-tools
> - android-udev
> - beets
> - bpytop
> - dvdbackup (used to maintain in aur)
> - cuda
> - fstrim
> - gcc10 (required for cuda)
> - handbrake
> - kitty
> - ncmpcpp
> - ninja
> - nextcloud-client
> - nlohmann-json
> - packer
> - pacman-contrib
> - pandoc
> - profile-cleaner
> - python-* (packages required for Aurweb see list from INSTALL)
> - screenfetch
> - spellcheck
> - signal-desktop
> - wxsvg (required from dvdbackup)
> - zsh-completions

There are a few packages in this list that has anywhere between 2 and 3
maintainers already. One maintainer is bad, two is good, but having 3+
maintainers is just painful to communicate if they are not all on the same page.
This applies mostly to docker and docker-compose on my end, but I suspect there
are more?

When we started doing this list it was mostly to highlight packages that need
more maintainers where we just had one, but I don't think it's super useful
listing up every one package you want to maintain which doesn't strictly need
more maintainers? To me this seems like listing up packages for the sake of
listing up packages.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- 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-general/attachments/20211101/f049a1ce/attachment.sig>