On 11/11/2018 18:29, Santiago Torres-Arias via aur-general wrote:
* Existing Trusted Users are not followed closely in their actions, and the quality of some packages for instance is more than questionable. * New applications are not carefully reviewed, and a several TUs seem to just vote “Yes” by default. * There is a general feeling of decreasing/not high enough quality in the packages provided in the community/ repository.
This first bit is mainly rhetorical: If these issues are combined, one thing which comes to mind is how the hypothetical situation where a TU uploads damaging/malicious content would be dealt with. For example, is there already some sort of "quality threshold" below which TU status is removed and packaging keys revoked? If there's already a process in place does it currently work and, if so, why are changes necessary? On 11/11/2018 18:29, Santiago Torres-Arias via aur-general wrote:
1. Add a council of TU's to introduce oversight on the whole voting process 2. Increase the minimum number of sponsors per application 3. Create a working group of TU's to review recent applications and warn TU's that do *not* appear to be performing their duties appropriately
This bit is not rhetorical: I might float another option, whereby TU applicants would go through a "probationary phase". This could be accomplished by having PKGBUILD changes submitted by the would-be TU but approved (and packaged) by existing TUs, e.g. the sponsor(s). I haven't used cgit enough to know how merge requests work there, but certainly with GitHub and GitLab (and Gitea etc.) PRs provide for a level of approval before being allowed to be merged.* This would allow quality issues to be caught and addressed before the packages hit the repos, and provide evidence to support a "full" TU status. I suspect that sort of review could also be shared as necessary, so any TU or developer can keep an eye on the process to make sure it's being done correctly. That might also combine nicely with number 3. * (Thinking about a naïve implementation; if a web-accessible PR system was useful and can't be done via cgit it could possibly be accomplished via a intermediary "mirror", e.g. Gitea mirrors the git.archlinux repo, applicants submit PRs against the mirror, sponsors approve and commit to git.archlinux)