[aur-general] AUR request mentality

[Tai-Lin Chu]

I feel those created by FredBezies and foutrelis are legit. There is
no reason for keeping packages for dead projects, and if upstream does
not create commit for more than n years the project is likely to be
dead. However what n should be is debatable.

I totally agree with the idea of having "package state": active or
inactive. I also think that we should have automated rules for aur
that help to remove bogus/dead-upstream/copyright-violating packages.
This is because everyone can upload package to aur, and only a few can
review them. We can hopefully discuss what rules to be implemented in
aur.


On Sun, Aug 17, 2014 at 1:30 AM, Brian F. G. Bidulock
<bidulock at openss7.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> carstene1ns,
>
> 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAlPwaD0ACgkQMYOP2up1d2V0lwCfcGKykMXMayxSZpc4oiIUy9GH
> ttMAoNM9QqPGXhe+JUYj5GS+Fp/Hvg+I
> =7yo3
> -----END PGP SIGNATURE-----