[aur-general] AUR request mentality
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. ## (1)This goes for both the requester and the TU that accepts it. I have seen requests that consisted only of two words. Back then, when we were forced to use email, you could read at least a whole sentence and have a rationale. Also some TUs do not seem to care about providing a reason, why a certain request has been accepted or declined. There was a feedback mail back then, so the requester knew there was someone working on it. (2)Orphan requests have a grace period of 14 days. That is good, but for other requests there is none. So packages get deleted before they even could get fixed. Some TUs do not even question the reason for the request and just delete it without investigating. Now you might ask me to provide some evidence... Let's blame two users today: FredBezies and foutrelis. FredBezies seems to try finding "dead projects" in the AUR. He does so by clicking on the homepage link and if it does not display the project website, he files a deletion request stating the project/homepage is dead (no googling, no word to the maintainer). Otherwise (for VCS packages) he looks at the last commit date and files a deletion request, if it has not been updated in 3 years, again with the reason "dead project". For example in case of the 'tasque-git' package the url of all gnome-related packages changed to include "/Apps/" in the wiki link and there has been no redirection for this particular package. However, there have been commits this year and the package is therefore not dead. foutrelis seem to like clean lists, as he just accepted any deletion request that was open today (including the absurd ones by FredBezies), without reading the mailing list before and without providing a reason. If it does not really make sense to answer questions and remarks like Scimmia and I (and others!) did, the aur-requests mailing list should be read-only. 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). best regards, carstene1ns
-----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-----
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-----
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 respectfully disagree. The upstream activity does not determine downstream use. Even if a project is dead it can still be used by many users. This is especially true for small programs and scripts where development stops simply because there's nothing left to develop. Having a separate "package state" field would be helpful for users, but in my opinion the removal of packages should be handled on a case by case basis. Deciding to keep or remove a package is (partially) dependant on whether or not people actually use that package. This is somewhat solved for the official packages by pkgstats, which "sends a list of installed packages to the Arch Linux project". I see no reason (and I can't find any online) why a system like this couldn't be implemented in the AUR.
I also think that we should have automated rules for aur that help to remove bogus/dead-upstream/copyright-violating packages.
Isn't that what TU's are for? I don't think it is easy (if possible at all) to automatically determine whether or not a package is bogus/violating copyright.
On Sun, 2014-08-17 at 11:36 +0200, Florian Dejonckheere wrote:
There is no reason for keeping packages for dead projects [snip]
I respectfully disagree. The upstream activity does not determine downstream use. Even if a project is dead it can still be used by many users. This is especially true for small programs and scripts where development stops simply because there's nothing left to develop.
+1
On 2014-08-17 12:58 +0200 Ralf Mardorf wrote:
On Sun, 2014-08-17 at 11:36 +0200, Florian Dejonckheere wrote:
There is no reason for keeping packages for dead projects [snip]
I respectfully disagree. The upstream activity does not determine downstream use. Even if a project is dead it can still be used by many users. This is especially true for small programs and scripts where development stops simply because there's nothing left to develop.
+1
I think there may be some confusion here. If upstream is present but inactive then the project should remain. If upstream no longer exists then there are no more sources. Of course, someone could upload those sources elsewhere for distribution (provided the license allows it). inactive != dead
On 17 Aug 2014 10:55, "Tai-Lin Chu" <tailinchu@gmail.com> wrote:
There is no reason for keeping packages for dead projects,
Why? If upstream is dead and the package is bitrotten, then yes, there is no reason to keep the package. On the other hand, if the project is dead, but the package compiles and it works, I don't think it should be removed. There are security implications, but AUR packages are unsupported anyway, so IMHO a dead upstream is not a compelling reason to delete a package from AUR. Lorenzo
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
Hello
Another point is that a lot of Trusted Users unfortunately don't seem to follow the aur-requests mailing list.
I had the same impression but I wonder how this is possible or admitted. Considering that the actual state of the requests web section won't give space to discussions or clarifications the reading of the aur-requests ML shouldn't be optional but absolutely a requirement for a TU. Best regards -- Fabio Castelli aka Muflone
What I suggest is to introduce such a locking mechanism for deletion requests as well.
Such mechanism should be also implemented in the merge requests as well if two packages come from different maintainers, at least to give both maintainers the time to react or communicate asking to cancel the merge. -- Fabio Castelli aka Muflone
On Sunday 17 August 2014 13:04:29 Muflone wrote:
Such mechanism should be also implemented in the merge requests as well if two packages come from different maintainers, at least to give both maintainers the time to react or communicate asking to cancel the merge.
If we will add this rule, I think the maintainer of the package to which will be merged isn't needed in the most cases (in the most cases he will be happy to get some votes :)). -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarcanis@mail.ru ICQ: 407-398-235 Jabber: arcanis@jabber.ru
On 2014-08-17 11:36 +0200 Lukas Fleischer wrote:
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.
Incidentally, providing links on the action confirmation pages (e.g. Delete Package) would make final checks easier.
On Sunday 17 August 2014 08:47:40 carstene1ns wrote:
(1)inhibition threshold - It is much easier to remove a package now.
(1)This goes for both the requester and the TU that accepts it. I have seen requests that consisted only of two words. Back then, when we were forced to use email, you could read at least a whole sentence and have a rationale. Also some TUs do not seem to care about providing a reason, why a certain request has been accepted or declined. There was a feedback mail back then, so the requester knew there was someone working on it.
Yeah, there are requests that don't provide enough information. But most of these requests have been rejected. Some of these requests have been accepted, because TU have examined the package and found that the request is correct. And we don't describe the reason for the closure of requests as before, if we think that it is correct (and if there are no additions).
(2)response time - Requests get accepted before the package maintainer or others have time to explain or react.
(2)Orphan requests have a grace period of 14 days. That is good, but for other requests there is none. So packages get deleted before they even could get fixed. Some TUs do not even question the reason for the request and just delete it without investigating.
Orphan requests have a 14-days rule [1] (and had before). When web interface of sending requests was introduced, the preparatory contact with the current maintainer isn't needed anymore. Other request haven't this rule (and had not) and we accept them according to the request description.
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).
In my opinion TUs should *always* check a package under request. If sources are no longer available anywhere (such as for some of *berlios.de projects) it can be removed. If the package has not maintainer and if it has a few votes it can be removed too (since seems it is not interesting to anyone). As for me I don't think that we should remove useful packages even its upstream has no activity (if it is not broken of course). So I don't think that we need to change the current policy, but I'm open for discussion. 1. https://wiki.archlinux.org/index.php/AUR#Other_requests -- С уважением, Е.Алексеев. Sincerely yours, E.Alekseev. e-mail: darkarcanis@mail.ru ICQ: 407-398-235 Jabber: arcanis@jabber.ru
On 17/08/14 05:52 AM, Evgeniy Alekseev wrote:
In my opinion TUs should *always* check a package under request. If sources are no longer available anywhere (such as for some of *berlios.de projects) it can be removed. If the package has not maintainer and if it has a few votes it can be removed too (since seems it is not interesting to anyone). As for me I don't think that we should remove useful packages even its upstream has no activity (if it is not broken of course).
If it has known vulnerabilities, then I think it's a different story. However, we should probably start dealing with dead / poorly maintained projects in [extra] and [community] with known security holes before applying it as a standard for AUR packages...
First of all thanks to carstene1ns for opening a discussion on this issue. I've tried to do the same thing yesterday [1] but no discussions resulted in the aur-requests ML. I wonder if anyone ever read aur-requests.
(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.
+1
Now you might ask me to provide some evidence... Let's blame two users today: FredBezies and foutrelis.
-1 Let's avoid to "file bugs" for people that tries to help your community. Surely, there's a way to make things better, so come here and with your work show us how to do that better :)
foutrelis seem to like clean lists, as he just accepted any deletion request that was open today (including the absurd ones by FredBezies), without reading the mailing list before and without providing a reason. If it does not really make sense to answer questions and remarks like Scimmia and I (and others!) did, the aur-requests mailing list should be read-only.
I had a similar issue with a different TU (Xyne) [1] which merged a good working package [2] inside a broken unmaintained package [3] (moreover I think that packages owned by a TU should be ALWAYS discussed with the TU, maybe there's a better reason for a package exists) but I believe that he missed the previously message [4] written on the aur-requests ML.
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).
We could also find a way to avoid that TUs involuntarily tell people conflicting things. If a TU awaits a reply from a maintainer, another TU shouldn't be able to close or reject the same request or maybe he must know what he's doing. At the actual state the only usable channel is the aur-requests ML and it would offer a good way for interactions, archives included, opened also to discussions for packages maintainers or casual people that could be interested in the requests. However no-one seems to be interested in such ML, maybe for the too high number of notifications that "spams" the ML. [1] https://mailman.archlinux.org/pipermail/aur-requests/2014-August/001070.html [2] https://aur.archlinux.org/packages/gt/gtkparasite-gtk3-git/PKGBUILD [3] https://aur.archlinux.org/packages/gtkparasite-git/ [4] https://mailman.archlinux.org/pipermail/aur-requests/2014-August/001022.html Best regards -- Fabio Castelli aka Muflone
Perhaps we could treat the aur-requests more like a bug tracker ? a possible flow : request is filed and gets unassigned status TUs review unassigned requests If they feel they are right person to handle it, they assign it to themselves. request status changes to assigned, and the TU is now responsible for handling the request. If they are not, they leave the request unassigned, maybe post something why they are not qualified. Once a request has assigned status, policy rules for such a type of request are added to the request. Only the assigned TU can accept or deny a request.
In fact, AUR misses git and a bug tracker per package. Now, package improvements suggestions need to be written in the comments, it's not very efficient. Another problem : often I see packages where the last comment reports a problem already fixed, because the maintainer didn't replied. A bug tracker would improve the process.
On Sun, 17 Aug 2014 at 14:43:13, Yamakaky wrote:
In fact, AUR misses git and a bug tracker per package. Now, package improvements suggestions need to be written in the comments, it's not very efficient.
Another problem : often I see packages where the last comment reports a problem already fixed, because the maintainer didn't replied. A bug tracker would improve the process.
These things are already being worked on. However, this is completely off-topic, so let's not discuss it here.
These things are already being worked on. However, this is completely off-topic, so let's not discuss it here.
Cool ! Sorry for the distraction.
On Sun, 17 Aug 2014 at 14:35:21, LoneVVolf wrote:
Perhaps we could treat the aur-requests more like a bug tracker ?
a possible flow :
request is filed and gets unassigned status
TUs review unassigned requests
If they feel they are right person to handle it, they assign it to themselves. request status changes to assigned, and the TU is now responsible for handling the request.
If they are not, they leave the request unassigned, maybe post something why they are not qualified.
Fixing a bug can take a lot of time and might require someone with special knowledge. Accepting a package request literally takes a couple of seconds (read the reason, double-check whether it is valid, click a link) and every Trusted User should be able to decide whether a request is valid or not. If a request is controversial, a TU should sent a short email to the mailing list and the request should be marked in the request list (can be done automatically). Any additional administrative burden is counterproductive.
Once a request has assigned status, policy rules for such a type of request are added to the request. Only the assigned TU can accept or deny a request.
On 2014-08-17 13:38 +0200 Muflone wrote:
Let's avoid to "file bugs" for people that tries to help your community. ... I had a similar issue with a different TU (Xyne)
:P (Don't worry, I don't mind being singled out.) I did indeed miss the discussion on aur-requests. I saw that the request had been made by Scimmia and the given reason was one that appeared legitimate, so I did not check the packages as I should have prior to the merge. I agree with your points and I apologize for the mistake. While the new interface makes some things easier, the need to correlate requests on the interface with discussions on the mailing list adds more work for TUs compared to the previous system in which everything was on the mailing list. I have been negligent in this regard but I will be more diligent in from now on. The idea of using a real bug-tracker was mentioned in another branch of this discussion. I like the idea of keeping actions and discussion in the same place. Depending on the feature set this could simplify management of the AUR. I just hope that such usability will not require prohibitive complexity in the backend. Regards, Xyne
On 2014-08-17 11:42, Xyne wrote:
On 2014-08-17 13:38 +0200 Muflone wrote:
Let's avoid to "file bugs" for people that tries to help your community. ... I had a similar issue with a different TU (Xyne)
:P (Don't worry, I don't mind being singled out.)
I did indeed miss the discussion on aur-requests. I saw that the request had been made by Scimmia and the given reason was one that appeared legitimate, so I did not check the packages as I should have prior to the merge.
I agree with your points and I apologize for the mistake.
And the reason was legit, Muflone agrees; it was more my lack of checking to make sure the current package was in good shape. gtkparasite-git was a package I fixed up a while back, so I kind of keep an eye on it. I saw that it had been updated upstream for GTK3, but didn't actually build and try it. I'll take more care in the future.
While the new interface makes some things easier, the need to correlate requests on the interface with discussions on the mailing list adds more work for TUs compared to the previous system in which everything was on the mailing list. I have been negligent in this regard but I will be more diligent in from now on.
The idea of using a real bug-tracker was mentioned in another branch of this discussion. I like the idea of keeping actions and discussion in the same place. Depending on the feature set this could simplify management of the AUR. I just hope that such usability will not require prohibitive complexity in the backend.
Regards, Xyne
participants (14)
-
Brian F. G. Bidulock
-
carstene1ns
-
Daniel Micay
-
Doug Newgard
-
Evgeniy Alekseev
-
Florian Dejonckheere
-
LoneVVolf
-
Lorenzo Bandieri
-
Lukas Fleischer
-
Muflone
-
Ralf Mardorf
-
Tai-Lin Chu
-
Xyne
-
Yamakaky