[aur-general] AUR request mentality

Lukas Fleischer archlinux at cryptocrack.de
Sun Aug 17 05:36:33 EDT 2014

On Sun, 17 Aug 2014 at 08:47:40, carstene1ns wrote:
> While the new AUR request functionality is a good thing and widely
> accepted (over 500 requests yet), it also brings us some problems:
> (1)inhibition threshold - It is much easier to remove a package now.
> (2)response time - Requests get accepted before the package maintainer
> or others have time to explain or react.
> There may be other problems, but these two bugged me since it was
> implemented.
> ## For the tl;dr version, please skip the following remarks. ##
> [...]
> tl;dr:
> What can we do to make things better? Should we (re)write the policy for
> TUs about accepting AUR requests? They should at least investigate.
> I think a good start would be to have users provide real reasons for
> deleting a package and trying to fix them otherwise (themselves or with
> help from the maintainer).

Policies are important but I think it is at least as important to have a
user interface that makes it easy (natural) to comply with them. Let me
give an example for that: When the package request interface was
introduced, all orphan requests were accepted before the expiration of
the grace period, even though our package request guidelines were still
the same. Why? The new user interface makes it much easier to go through
the list and accept requests, while checking whether the request is
older than two weeks was just as "hard" as it had been before. In a
minor release, I added a feature that locks new orphan requests for 14
days and now, accepting a locked request is much more work than
accepting an unlocked request (requires 4 clicks instead of 1 click). It
looks like that worked out pretty well.

What I suggest is to introduce such a locking mechanism for deletion
requests as well. One might argue that deletion requests are often
uncontroversial (upstream has been dead for >3 years, sources are gone,
there is no fork) but then again, it doesn't really matter whether the
broken package stays in the AUR for another 14 days. It might be a good
idea to skip (or shorten) the grace period if the request is filed by
the current package maintainer, though.

Another point is that a lot of Trusted Users unfortunately don't seem to
follow the aur-requests mailing list. And the package request interface
is not linked to the mailing list in any way. So, while it is
technically more difficult than the simple locking idea, it may also be
desirable to have the AUR check the mailing list (or the mailing list
archives) and mark a request if there is any discussion, preferably with
a link to the archives.

> best regards,
> carstene1ns

More information about the aur-general mailing list