[aur-general] AUR request mentality

Brian F. G. Bidulock bidulock at openss7.org
Sun Aug 17 04:30:56 EDT 2014

Hash: SHA1


On Sun, 17 Aug 2014, 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.

I agree with most of your points; but lets not blame users, TUs or
otherwise.  I think we all have an interest in making Arch better.

I think that the orphan requests are being handled very much as
before, although perhaps will a litte less feedback to the requestor.
I still get some approved and some declined, both usually with
good reason.

Deletions, on the other hand, appear to be accepted more than before.
Quite often I would see a TU decline a deletion request if the
PKGBUILD could ever be useful later and I think that was a good
approach.  A dead former upstream is usually not enough, all dockapps
from dockapps.windowmaker.org would be gone now if that was the
case, not to mention many projects that were formerly hosted on
berlios.de.  Having the former PKGBUILD on the AUR is a benefit
for trying to resurrect a source of the upstream package.

Request #511 (catwm-git) is a good example.  The PKGBUILD would have
been helpful as there is a fork on github that was updated 7 days
ago and the old PKGBUILD would have helped by merely shifting the
git source to the fork from the missing repository that it was
based upon.

Perhaps we could have a state of an AUR package that marks it
as a candidate for deletion, but does not finally delete its
PKGBUILD files until it is obvious that nobody is going to rescue
it.  Let's see, more than an orphan, how about a zombie?

- --brian

Version: GnuPG v1.4.9 (GNU/Linux)


More information about the aur-general mailing list