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@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-----