Debian doesn't do a good job in making life easier for its maintainers. https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
I respect the fact that current Debian development practices have carried the OS this far, but lowering the barrier to entry for volunteers to help maintain the OS going forward could only be a good thing.
The most obvious in the current context is possibly well intentioned amateurs proposing LLM generated patches for the usual developers to fritter away their time on until patience runs out.
I have seen maintainers who, after a few rounds of code review on a PR that's not making any progress, close the PR and say, "I appreciate your efforts but this is taking up too much time. Please address the remaining issues independently and submit a new PR once you believe you have addressed them all."
The other possibility is that the LLM-generated patch is actually fine. If it looks okay and passes the automated tests, then I can't see why it shouldn't be merged. (Assuming Debian doesn't or hasn't enacted a blanket-ban on LLM-generated code.)
What does a maintainer realistically do?
He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot.
In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on.
Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software.
I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.
Debian maintainers have to coax upstream packages to behave like other Debian packages and use supported linked dependencies. This covers everything from log and config file locations, startup scripts patching dependencies to match the versions supported by the release, backporting security updates, and documenting.
I trust Debian (and in turn Debian maintainers) more than I trust the upstream developer of lib-random-4-dev. I only ever had to build a custom package from source a handful of times.
I don't doubt it: isn't the breadth of Linux distro flavors and philosophies an amazing thing?
Generalley, ports-like package repos (all package build recipes in one repo) are really beneficial for large-scale operations or simply rollbacks. Being able to bootstrap the distro from a git repo and a well-defined set of bootstrap tools is really nice. try that with debian.
See Void Linux and Alpine for a simple, yet refreshing aproach to distro package maintenance, with low overhead.
It's easier because you get a sane shell instead of a poor reimplementation of a tiny subset of one.
I maintain many aur packages, and wrote the first one in half an hour, knowing nothing about Arch packaging at the time. Now it takes me maybe 5-10 minutes to package a small application that adheres to the standard conventions.
I spent maybe two days on my first Debian package. It was also the last one (not really, but almost so).