[aur-general] On TU application, TU participation and community/ package quality

[Jonathon Fernyhough]

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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181111/982b7cc6/attachment.asc>