Interesting discussion: https://old.reddit.com/r/archlinux/comments/s5id1m/usersubmitted_package_upd... https://archive.is/9wwNm Quoting: -------- A lot of packages are flagged out of date, some even for security issues. Some have no maintainer. Many have inactive maintainers and have been left to rot. Active developer resources are limited. I'd like to describe how the situation could be improved with the help of the community in a way that may not have been brought up before. Arch packages are built from very easy-to-read PKGBUILD files, similar to Makefiles. In short, users would be able to submit diffs to PKGBUILDs in the repo for updates, but not actually upload binary packages, similar to how the AUR works (and for the same reason): A diff to the PKGBUILD can be audited for errors or malice in a matter of seconds, while a (currently unreproduced) user-submitted binary shouldn't be trusted at all. The only difference in this scenario is that a trusted committer (who may or may not be the package maintainer) would have to look at the diff and commit the update to the repo, rather than users committing them. On to the first issue: that text I put in bold. Several Arch devs have mentioned (in public and private) that the culture of not "stepping on anyone's toes" prevents them from updating packages that are maintained by someone else. Conversely, there was a talk at the last Arch Conf where Lavente said he wanted more packages to be co-maintained by multiple people in case one wasn't available to actually maintain it. I don't have a technical solution to this people problem -- devs would simply have to live with the fact that users need fixes and sometimes another dev will update your package for you. Don't take it personally. The other issue: Arch has a legacy separation of core, extra, and community repos. Only "developers" can commit to core and extra, while "trusted users" are restricted to the community repo. I'm 100% sure everyone reading this has all three repos enabled, thus destroying any notion of community being "less trusted" than the other two. Having the core repo require an extra sign-off and some testing is a good idea, but otherwise I think this artificial separation should be done away with. One problem with the current situation is that "trusted users" may be available and willing to help, but can't actually update anything in the core or extra repos. Onboarding more of them doesn't help either because it takes months or years for them to be promoted to "developers," if it happens at all. So back on topic: How would users actually submit the updates to the PKGBUILDs? Eventually, when the Arch gitlab allows registration, they could be very simply sent as pull requests. Right now they would have to be sent through the existing bug tracker (the same one that specifically disallows what I'm suggesting). After being reviewed and committed, a package could be built by the developer who chose to take it... or there could be bigger infrastructure changes to save them time and effort in the long run. Here I'm talking about a large number of project devs committing the PKGBUILD changes, but only one build server (or farm) doing the compilation and (optionally through another special server) signing of the results. This is basically how it works in BSD for their package repos. The server(s) could automatically build any committed update every hour, or devs could issue a "queue this package" type of command on it, or some other way. That kind of setup would have the side benefit of only requiring users to trust one signing key, rather than a keyring of dozens of people around the world with varying degrees of personal security, and trusting the binaries sometimes just built on their daily laptops. It would also allow the package database to be signed more easily, which has been a big problem for a long time. (This is probably better for a separate discussion.) tl;dr: Users submit PKGBUILD diffs, anyone with commit access builds and pushes them. What do you think?