About user MarsSeed's script-like mass requests
My opinion on this first: I'm not against his intention to clean AUR. I'm against using some self-written scripts to mass-file requests to certain packages just based on t heir traits, like keywords, names, or whatever. I'm also against doing so by hand, which is basically using yourself as a request machine. I think most of us would agree that every request, no matter they're for orphan, merge, or deletion, need to be thought carefully and sent with details associated close ly with it. And blindly filing them just adds burden to PMs as this leaves research to be done to PMs. The direct reason I want to post this is reading following requests: PRQ#51267[1], PRQ#51269[2], PRQ#51270[3] and PRQ#51271[4], these affects armcl-opencl[5], arm-linux -gnueabihf-armcl-neon[6], aarch64-linux-gnu-armcl-opencl+neon[7] and aarch64-linux-gnu-armcl-neon[8] accordingly. If you take a look at the packages, you could clearly see they're for cross-compiling on an x86_64 ArchLinux host to an ARM target. These are just like aarch64-linux-gn u-gcc, arm-linux-gnueabihf-gcc, etc in the official repos, and they have useful functionality like opencl and neon support. But how did MarsSeed write his deletion requests? Each of them are simply just the following message copy and pasted, and there're more, tens of, if not hundreds of oth er requests with pasted detail same as them:
ARM-only packages belong to ArchLinuxARM.org repos, not AUR:
https://archlinuxarm.org/packages
https://archlinuxarm.org/forum/viewtopic.php?f=9&t=2675 https://archlinuxarm.org/forum/viewforum.php?f=4
AUR is primarily for Arch Linux, so packages here must work with the x86_64 architecture: https://wiki.archlinux.org/title/Arch_package_guidelines#Architectures
I think we could say these requests are clearly filed by some automated process that's triggered on any package with arm or aarch64 keywords. But the process catches wr ong targets and these requests would result in either wrongly deleted packages or increased labor for PMs to read the PKGBUILDs by themselves before rejecting them. This is not right. This, an automated request filing process, should not be the way a user files their package requests. If an automated process just catches all packag es with some traits and filing requests is acceptable, then why is a user needed in the process at all? The user account is just like an API key for a bot program in that case. And if doing so is acceptable, why not just give the script or whatever tech behind the automated process to PMs so they can even save the time needed to check requests list? Still, I appreciate the amount of time MarsSeed put previously on clearing the AUR. I think there might be ~10k requests filed by him ever since he joined AUR (based on a simple search of 'MarsSeed [1]' in the aur-requests mailing list), and I'd like to see him continuing on his work, but not in such robotic way.
Hello, I would like to comment and bring in another email I sent recently. From https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org/...:
I think something which does need to be brought up is a feature to mass delete package and their subpackages, in a dependency style way. If some software has hundreds of plugins packaged for it, and the main package is deleted, then (as far as I am aware), all the plugins need to be flagged for deletion which then means the requests get flooded. Maybe there is a feature which exists already, but I am not aware of it (maybe a package maintainer can comment on this?).
I think this point I made here is very relevant, there is some legitimate use for bulk deletion requests, when you are blanket deleting a large number of similar packages. However, I feel this would also promote the deletion of useful packages, simply for being orphaned, which I also discussed in the thread I linked above. However I do feel this feature would massively fix the ML spam, and no offense to zoorat, marsseed and anyone else who is attempting to clean up the AUR, but it is painful to look through requests as a normal user when you fill it with 100s of requests every day.
I think we could say these requests are clearly filed by some automated process that's triggered on any package with arm or aarch64 keywords. But the process catches wr ong targets and these requests would result in either wrongly deleted packages or increased labor for PMs to read the PKGBUILDs by themselves before rejecting them.
Well I think this is up to the PMs themselves, if they say there is nothing wrong with botting the AUR to attempt to detect bad PKGBUILDs, then its them who deals with the spam. However there is a lot to be said with the response time of legitimate requests, it does seem like MarsSeed has priority, I have seen their requests be handle very quickly, while others wait for months and get caught in the backlog. I would like to say, I am aware that PMs pick what is easy to do, and leave the more complex time consuming ones for when they get more time, but it does seem like there is some bias here... possibly due to the shear quantity of requests that it overshadows individual users.
This is not right. This, an automated request filing process, should not be the way a user files their package requests. If an automated process just catches all packag es with some traits and filing requests is acceptable, then why is a user needed in the process at all? The user account is just like an API key for a bot program in that case. And if doing so is acceptable, why not just give the script or whatever tech behind the automated process to PMs so they can even save the time needed to check requests list?
Again it is up to the staff how they administrate their platform, and if they deem that this is fine, then there is nothing you can do about it.
Still, I appreciate the amount of time MarsSeed put previously on clearing the AUR. I think there might be ~10k requests filed by him ever since he joined AUR (based on a simple search of 'MarsSeed [1]' in the aur-requests mailing list), and I'd like to see him continuing on his work, but not in such robotic way.
In general, people who have the insane numbers in the AUR, use massive amounts of automation to try to replace labour time. However this, in my opinion, yields lower quality packages, and worse, causes pollution of the AUR where packages are automatically bumped but yet don't work because someone left their Github CI running for the last 5 years and haven't checked it since. These are hard to get orphaned too, because it seems like an active package, but in fact, it is just a bot keeping its pkgver up to date. Anyways, TL;DR the suggestion I made above might be a good way to help deal with this problem. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
Hi there I won't enter into all the discussion details but an explicit accusation needs be cleared:
However there is a lot to be said with the response time of legitimate requests, it does seem like MarsSeed has priority, I have seen their requests be handle very quickly, while others wait for months and get caught in the backlog.
This is a 100% false argument: there are so many requests to process, most of them made by MarsSeed, so it's obvious most of the responses are relative to MarsSeed requests. Also what happened the day before this discussion started, seemed to demonstrate the exact opposite: [1] [2] [3] [4] [5] [6] [7] I repeat, this could seem we give priority to 7Ji (which is the OP of this whole discussion), but I confirm this is simply a matter of luck and package maintainership (see below). Also some of MarsSeed's requests are being rejected after evaluation if the reasons are not enough to accept. Archives are public for anyone. Requests made by the package maintainers (as the previous 7 indicated before) are processed quicker as the package's maintainer should know better the state of the package he's filing requests for. Also, I tend to give priority to orphan requests, as someone else is awaiting to fix packages issues, so giving priority to these requests the packages will be fixed quicker. So, please, Polarian, don't discredit the staff members and respect the work done which is sometimes very heavy and tiring and wasting my time in explaining how the things are is more time I have subtract. I found this your accusation very rude and ungrateful, I hope it was done in good faith, not thinking enough (you never contacted me to asking such details). Having said this, actually we have more than 3000 pending requests, so it's impossible to remember who is awaiting in the queue. Whenever his turn comes the request will be processed like for anyone else. In the 98% of the times, a request is accepted or rejected. The remaining cases are awaiting for requester or maintainer answer. In some rare cases (less than 1 of 100) if I don't understand the issue or I'm unable to understand how the things are I leave the package request to someone else. Also each PM does evaluate the requests by interpreting what the requester wrote, so a clearer explanation in the requests could give better result and quicker response time. I don't even care about the names in the requests, seriously. Incomplete requests, duplicated packages to fix an original package issue (X package is buggy, this Y package of mine fixes that, please merge), at the contrary require more time and sometimes the answers I need to have before processing the request, never come, thus burdening the request in an eternal oblivion. MarsSeed requests are often, so far, the most precise, clear, well explained, with external links and frequently updated with additional details. People should instead learn from his way to report packages. Also, PMs do mistakes, so in the case some wrong thing happens, please contact the PM and ask for a revision or clarification. Best regards [1] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... [2] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... [3] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... [4] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... [5] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... [6] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... [7] https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... -- Fabio Castelli aka Muflone
Hello,
Also some of MarsSeed's requests are being rejected after evaluation if the reasons are not enough to accept. Archives are public for anyone.
I am aware of this, I made the point of the fact the archives are filled with a few usernames, and them usernames only, one of them is "MarsSeed". I can never seem to find anything within the archives, but then again, that might be incompetence on my part.
Also, I tend to give priority to orphan requests, as someone else is awaiting to fix packages issues, so giving priority to these requests the packages will be fixed quicker.
I noticed this a lot, but it means merge requests take months to be accepted, and deletion requests can sit there for potentially years. I guess this isn't really anyones fault, but more the lack of manpower to deal with the influx of requests.
So, please, Polarian, don't discredit the staff members and respect the work done which is sometimes very heavy and tiring and wasting my time in explaining how the things are is more time I have subtract. I found this your accusation very rude and ungrateful, I hope it was done in good faith, not thinking enough (you never contacted me to asking such details).
I made an observation, hence the word "seems" was used, instead of an objective fact. I apologise that you disagree and believe that no unconscious bias was put into the situation, and that I got it wrong, but observations are in no way insults. I would also like to point out I have never complained how long I have to wait for requests, in fact, I normally just forget I even submitted a request. So I do not see how I am being ungrateful here, it wasn't a complaint, nor was it an insult...
Having said this, actually we have more than 3000 pending requests, so it's impossible to remember who is awaiting in the queue. Whenever his turn comes the request will be processed like for anyone else. In the 98% of the times, a request is accepted or rejected. The remaining cases are awaiting for requester or maintainer answer. In some rare cases (less than 1 of 100) if I don't understand the issue or I'm unable to understand how the things are I leave the package request to someone else.
And if a large percentage of those requests were submitted by the same person, then it does give the viewpoint of a bias, because the same maintainer is seen being accepted/rejected within the archives. Maybe "bias" was the wrong word to use here, as instead of it being a bias, it is the staff trying to keep up with the ever increasing flood of requests as Arch grows bigger and bigger on a daily basis, and people like MarsSeed simply make the most requests, and thus has the most responses.
Also each PM does evaluate the requests by interpreting what the requester wrote, so a clearer explanation in the requests could give better result and quicker response time.
I don't even care about the names in the requests, seriously.
I think you took an observation as a complaint about your effectiveness, when it was not meant in that way. The entire reason I even pointed it out was to justify my suggestion, MarsSeed by numbers probably has the most requests dealt with, percentagely there could be a bias here, but that doesn't matter. My point was that the "bulk request" idea would fix this issue, instead of there being 700 requests which MarsSeed submitted and had dealt with, it was one request grouped together, this removes the illusion of a bias towards a single member as you can see "oh it was just 700 plugins for a package which no longer exists". That was my point, my point wasn't the staff being ineffective and I know how much effort you put into accepting requests, I believe you have dealt with the majority of my requests, it was never an insult, it was an observation to back my idea. It has been pointed out to me, making a suggestion only helps so far, what would be more helpful was if I submitted a patch implementing said suggestion, especially how developers probably do not have the time to implement a quality of life feature. TL;DR I was trying to help, nothing else.
Incomplete requests, duplicated packages to fix an original package issue (X package is buggy, this Y package of mine fixes that, please merge), at the contrary require more time and sometimes the answers I need to have before processing the request, never come, thus burdening the request in an eternal oblivion.
I believe these are the requests which make up the majority of the backlog. Linking back to the point made multiple times is the deletion requests for packages which are broken or unused libraries are very low priority and they take up so little space. In fact, I believe these should be proactively fixed instead of purged. The only packages left for deletion then would be those which can't be fixed (upstream disappeared for example), or for copyright issues or the other few edge cases, which would definitely lower the burden. Also I don't see why having unused libraries in the AUR is a bad thing, some people might link their personal projects against them, who knows. If it works who cares?
MarsSeed requests are often, so far, the most precise, clear, well explained, with external links and frequently updated with additional details. People should instead learn from his way to report packages.
Well there is no denying they have a ton of experience :P
Also, PMs do mistakes, so in the case some wrong thing happens, please contact the PM and ask for a revision or clarification.
I have had to do this in the past, we are all human after all :) I hope this clarifies my point, I did not mean to cause any offence, in fact I wasn't even questioning the role of PM's here, I was trying to offer up solutions to make this problem less of an issue. Can this flame war please end now? It seems like a ton of people have took offence over comments which were made in good faith to try to fix an issue, it does not seem likely any person in this thread has intentionally aimed to cause offence. I think a few reoccurring ideas which have been brought up in multiple threads is the following: - Clarify guidelines for AUR, with the amount of conflict it seems like the AUR wiki page needs serious analysis, maybe with examples of good and bad requests? (maybe this can be made a subpage of "how to make a request") - Discourage deletion requests for unused libraries and broken/outdated packages, at least until the PM's can catch back up with the current ocean of requests. It would also be nice if people stop submitted orphan requests 1 day after a flag because they are impatient, but nothing you can do about this and most of this can be fixed by simply seeing the maintainer respond. - Possibly implementing new features into AURweb? Like the bulk request feature I suggested, but this is a much more long term solution which would require a lot of time to implement too. I apologise to any staff members which took offence here, Muflone might not be the only one. MarsSeed, I was not insulting you in any way, I am aware you are passionate about contributing, but lets not turn passion into a flame war. Nobody here is out to get you, but you got to acknowledge that your requests are causing issues for PMs, whether they are useful or not, slowing down a little won't hurt :) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
Also, I tend to give priority to orphan requests, as someone else is awaiting to fix packages issues, so giving priority to these requests the packages will be fixed quicker. I noticed this a lot, but it means merge requests take months to be accepted, and deletion requests can sit there for potentially years.
Btw for the news, the actually oldest unhandled AUR request is since 2023-08-12, [awaiting for a response from a different maintainer] -- Fabio Castelli aka Muflone
Hello,
Btw for the news, the actually oldest unhandled AUR request is since 2023-08-12, [awaiting for a response from a different maintainer]
Ah, so there has been a lot of catching up then. I was just making a wild guess based on the time frame of this: https://lists.archlinux.org/hyperkitty/list/aur-requests@lists.archlinux.org... Which you kindly accepted :) I assumed that because this was a easyish request to deal with, that there would be tons of old difficult requests which still needed to be done, but I guess not \o/ Thanks for the correction! Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev
Hi, I am not going to respond to everything in this email it's way tooo long. But CC'ing zoorat/MarsSeed as they are discussed here. On 15/11/2023 11:28, 7Ji wrote:
My opinion on this first: I'm not against his intention to clean AUR. I'm against using some self-written scripts to mass-file requests to certain packages just based on t heir traits, like keywords, names, or whatever. I'm also against doing so by hand, which is basically using yourself as a request machine.
Agreed.
I think most of us would agree that every request, no matter they're for orphan, merge, or deletion, need to be thought carefully and sent with details associated close ly with it. And blindly filing them just adds burden to PMs as this leaves research to be done to PMs.
This has been the case for half a year now?
The direct reason I want to post this is reading following requests: PRQ#51267[1], PRQ#51269[2], PRQ#51270[3] and PRQ#51271[4], these affects armcl-opencl[5], arm-linux -gnueabihf-armcl-neon[6], aarch64-linux-gnu-armcl-opencl+neon[7] and aarch64-linux-gnu-armcl-neon[8] accordingly. <SNIP> This is not right. This, an automated request filing process, should not be the way a user files their package requests. If an automated process just catches all packag es with some traits and filing requests is acceptable, then why is a user needed in the process at all? The user account is just like an API key for a bot program in that case. And if doing so is acceptable, why not just give the script or whatever tech behind the automated process to PMs so they can even save the time needed to check requests list?
I cannot comment on if these packages should go or not but skimming through the thousands of requests we have there are several categories of request: * Deletion request because the source is gone * Deleting unneeded libs because nothing in the AUR uses it Leaving packages in the AUR which have no source isn't helping anyone, "unneeeded libraries" is a bit of a problematic as they could be useful you just don't know. However AUR Requests can only be handled one by one so going through the requests is a painful task and discouraging as there are currently 59 pages to go through. Getting this automated in AURWeb itself would be a lot more helpful then filling ~ 50k deletion requests. Filling this amount of requests only leads to a burnout of the AUR Staff trying to get a hold of the requests situation. So I would like to kinda ask Marsseed/Zoorat to stop filling requests until we can get a hold on the massive backlog of open requests. Thanks in advance, Jelle
Hi all, Please don't frame me with baseless accusations like the statement that I am using scripts to file mass requests. I emphatically do not do that. I have filed every single request by hand, and with relevant evaluation behind all of them.
The direct reason I want to post this is reading following requests: PRQ#51267[1], PRQ#51269[2], PRQ#51270[3] and PRQ#51271[4], these affects armcl-opencl[5], arm-linux -gnueabihf-armcl-neon[6], aarch64-linux-gnu-armcl-opencl+neon[7] and aarch64-linux-gnu-armcl-neon[8] accordingly. <SNIP> This is not right. This, an automated request filing process, should not be the way a user files their package requests. If an automated process just catches all packag es with some traits and filing requests is acceptable, then why is a user needed in the process at all? The user account is just like an API key for a bot program in that case.
'armcl' stands for ARM ComputeLibrary. For using ARM-based SoC's and their GPU component for mass parallellized, floating point heavy computation. Which clearly won't work with the x86 architecture. How is this just irrelevant and baseless spam? Again, I have filed those requests as well by hand, with proper reasoning to back them up. Based on clarity that such packages are not in accordance with AUR guidelines.
I think most of us would agree that every request, no matter they're for orphan, merge, or deletion, need to be thought carefully and sent with details associated close ly with it. And blindly filing them just adds burden to PMs as this leaves research to be done to PMs.
I object to this insinuated classification. I do not file anything blindly. I am always carefully considering all the facts and apply the AUR submission guidelines and Arch packaging guidelines as the basis for my evaluation, and refer to those in my submission messages. I also respond every time, when it's relevant, to maintainer or other list member or AUR commenter, if they object or if they have further queries. @7Ji has responded to one of my deletion request at a point when I only submitted a few ARM-related ones. In my response, I provided further links to back up my claim that ARM-only packages are not in accordance with guidelines. I also provided a link to precedent, i.e. one of the deletion request threads pertaining to an ARM-only package, which included @muflone's reasoning for dropping said ARM-only package. In followup to that, @7Ji has mass-filed 40+ deletion requests of their own, for other ARM-only packages, and for some other package that are not necessarily ARM only (and @muflone has rejected a few of them because of this). So who is the one who just blindly copy-pastes requests? It's definitely not me. When I copy-paste, still I adjust the message then, to accommodate the package-specific facts. When pasting links to deletion requests for ARM-only packages, I do so with the intention to give pointers to maintainers about the ways of contributing to ArchLinuxARM.org and submitting self-made packages there.
"unneeeded libraries" is a bit of a problematic as they could be useful you just don't know.
I don't think this is problematic. Packages that are several years old, (like 6-8-10+ years) and don't have user comments, or have them from many many years ago, are indications that they might not be used. It is especially a well-founded statement if there are newer/supported/maintained alternatives. Some package owners are putting efforts to care for legacy low-level libraries for which only unused, in many cases defunct downstream packages exist on AUR. So these maintainers of said low-level libraries waste their efforts. By deleting truly unneeded packages, their work can be put to better use. And btw, for at least 90+% of my deletion requests, there have been no maintainer or user response whatsoever during their 2+ months existence. And among the remaining 10%, in at least 8 percentage point of the cases the response was just that maintainer disowned the package.
Filling this amount of requests only leads to a burnout of the AUR Staff trying to get a hold of the requests situation.
The burnout didn't seem to have happened because of me. There are only a few AUR Package Maintainers who actively attend to requests, with @muflone alone handling 98+% of everything himself. As per AUR dashboard, there are currently 64 users in the 'Package Maintainers' category. Maybe some of them could be asked to help out a little bit, but *regularly*. Which overall could significantly improve the response time. Most of them have done zero request processing during the last 2-3 years. In response to an earlier mail in this thread by @ Polarian:
However there is a lot to be said with the response time of legitimate requests, it does seem like MarsSeed has priority, I have seen their requests be handle very quickly, while others wait for months and get caught in the backlog.
Again, baseless accusation that any of my requests are not legitimate. All of them are genuine and good faith requests. Maybe not all of them are deemed acceptable in the end, but that does not discredit their initial submission. @Polarian, I don't see where you do get the "priority treatment" impression about my requests. I see the opposite. It seems it's almost only @muflone opens my now 3.5 month old requests and processes them, with one or two other PM's processing some additional ones during the past 24 hours. On the other hand, there are occasions when some other PM's process the newest requests filed by others, instead of going for the oldest ones. I think they should be advised to start from the least recently filed ones. The case that I see actually is that some among the otherwise occasionally active PM's appear to avoid reading and evaluating my requests altogether. But those who don't do a bit of effort at all to engage with my requests should not (pre-) judge them. Back to the priority question: Maintainers's own requests are an exception, for which there is a filter on AURweb. It is the right thing to do in my opinion to address them earlier than third parties' ones - and several PM's do tend to those, which I welcome. Regarding the merit of my activities: There have been users who sent positive feedback to me, thanking me for my efforts in contributing to useful housekeeping on AUR. I also submit many easy-to-implement packaging improvement suggestions to maintainers, and I also report bugs or failures, with solution suggestions if I can come up with them (obviously it is not always the case, as many things are outside my area of expertise). Back to critics: Those who assert that most of my requests are illegitimate are discrediting @muflone most of all, because he is the one who has treated the supermajority of my requests. He has so far accepted, by my rough guesstimate, at least 98% or more among those. Are you saying that he is doing questionable and erratic work? I myself do not see that view justified at all. Again quoting from the mail I am currently responding to:
Getting this automated in AURWeb itself would be a lot more helpful then filling ~ 50k deletion requests.
I don't know where the 50k (50.000) figure comes from. I have filed more than an order of magnitude lower amount of that during the last 3 years. I have also learned from my initial mistakes and now I try to include a little bit more information in each submission. Of course, I also try to be brief if possible.
As the AUR has been a low policing zone for most of its existence, with no pre-submission and during-maintenance code review gating, it is inevitable that there is a huge amount of dead weight in it. With older versions of PKGBUILDs still existing when a newer one was already submitted maybe due to VCS repository migration from one type to another, or when one library gets deprecated by upstream in favor of others.
During the last half year, I have focused predominantly on packages that intended to be drop-in replacements of Arch repo packages but which were defunct in one way or another. These packages had the highest exposure to users while still being dead or unneeded, or just plain duplicates, new or old. In consequence of their deletion, people have much lower chance of choosing alternatives that are not proper or viable ones.
My other focus was dead/unneeded Python2 packages and also dead Python3 ones.
Of course I also filed many requests based on the long unavailability of the sources and/or mandatory dependencies. (I usually check web.archive.org as well to get a better picture on how far back the dependencies have been missing.)
Many of my requests follow similar, considered reasoning for similar cases that are covered by filings from more veteran and well-respected AUR community members like @a821 and @FabioLolix. I don't see why my requests in particular would be less valid than theirs, if both theirs and mine have well-founded arguments based on the same kinds of issues that make them choose to file those requests.
With AUR having 86.000+ pkgbases and still keep packages from 10+ years ago, it is not so outrageous to see thousands of requests filed.
I don't think that sanctioning legitimate community members like me in their legitimate requests is a just and valid solution for a problem that clearly has more adequate ways to handle.
One better way could be to try to involve more PM's amont the 64 in total, with more regularity. Another could be to add issue category tags to requests, like in GitHub/GitLab issues, so that PM's could more easily filter based on those. If such system were in place, prioritization would be facilitated tremendously, e.g. severe security and system integrity violations could be separated from e.g. "unused packages" low-importance housekeeping.
Orphan requests should also be enhanced, e.g. if lingering for weeks and months without any response by maintainer, any AUR comment by maintainer, and any commit by maintainer, then the should be auto-accepted.
AUR rules that are vague could also be clarified further, to reduce ambiguity in evaluating the legitimacy of requests.
There are use cases that are not addressed at all by current guidelines. E.g., AppImage based binary packages and their naming, and also naming Electron based packages that do or do not bundle their own copy of the electron runtime.
In case some AUR packages are kept for extra-AUR applications that are not submitted, the proper solution is to create helper metapackages that hold the needed dependencies, so that the extra-AUR applications can easily be installed and made to work.
Otherwise "dangling" libraries with no other packages to use them with just look utterly useless on AUR.
AUR guidelines should set this requirement, spelling out explicitly that without legitimate consumers on AUR, many-years-old libraries without any downstream dependents, especially if they are also lacking any or at least a responsive maintainer, are fair game for deletion.
Automated checking systems could also help, though deleting packages based solely on bots' evaluation could also be problematic. (Although some obvious filters could be used for auto-deletion with maybe a deadline, e.g. for using sudo inside the PKGBUILD.)
Nevertheless, a human like myself is actually a valuable evaluator when it comes to submissions, despite the hostile and demeaning accusations and classification that I have seen levied against me.
I think also that fair treatment is a necessity when one is accused and framed, and such attacks should be called out rather than being tolerated or outright condoned. If AUR staff gives in to such, that would just alienate good-faith members like me.
Thank you for considering my feedback.
I am grateful for all the dedication and care that all Arch/AUR staff and all community members demonstrate through their continuous efforts.
Take care,
Marcell Mészáros (MarsSeed)
On 15 November 2023 12:13:11 GMT+01:00, Jelle van der Waa
Hi,
I am not going to respond to everything in this email it's way tooo long. But CC'ing zoorat/MarsSeed as they are discussed here.
On 15/11/2023 11:28, 7Ji wrote:
My opinion on this first: I'm not against his intention to clean AUR. I'm against using some self-written scripts to mass-file requests to certain packages just based on t heir traits, like keywords, names, or whatever. I'm also against doing so by hand, which is basically using yourself as a request machine.
Agreed.
I think most of us would agree that every request, no matter they're for orphan, merge, or deletion, need to be thought carefully and sent with details associated close ly with it. And blindly filing them just adds burden to PMs as this leaves research to be done to PMs.
This has been the case for half a year now?
The direct reason I want to post this is reading following requests: PRQ#51267[1], PRQ#51269[2], PRQ#51270[3] and PRQ#51271[4], these affects armcl-opencl[5], arm-linux -gnueabihf-armcl-neon[6], aarch64-linux-gnu-armcl-opencl+neon[7] and aarch64-linux-gnu-armcl-neon[8] accordingly. <SNIP> This is not right. This, an automated request filing process, should not be the way a user files their package requests. If an automated process just catches all packag es with some traits and filing requests is acceptable, then why is a user needed in the process at all? The user account is just like an API key for a bot program in that case. And if doing so is acceptable, why not just give the script or whatever tech behind the automated process to PMs so they can even save the time needed to check requests list?
I cannot comment on if these packages should go or not but skimming through the thousands of requests we have there are several categories of request:
* Deletion request because the source is gone * Deleting unneeded libs because nothing in the AUR uses it
Leaving packages in the AUR which have no source isn't helping anyone, "unneeeded libraries" is a bit of a problematic as they could be useful you just don't know.
However AUR Requests can only be handled one by one so going through the requests is a painful task and discouraging as there are currently 59 pages to go through. Getting this automated in AURWeb itself would be a lot more helpful then filling ~ 50k deletion requests.
Filling this amount of requests only leads to a burnout of the AUR Staff trying to get a hold of the requests situation. So I would like to kinda ask Marsseed/Zoorat to stop filling requests until we can get a hold on the massive backlog of open requests.
Thanks in advance,
Jelle
Please don't frame me with baseless accusations
In followup to that, @7Ji has mass-filed 40+ deletion requests of their own, for other ARM-only packages, and for some other package that are not necessarily ARM only (and @muflone has rejected a few of them because of this). So who is the one who just blindly copy-pastes requests? It's definitely not me.
My whole account just has 11 PRQs, 2 of which are merge, and 9 of them are deletion, all filed against my own packages, all accepted. None of them is "not necessarily ARM only (and @muflone has rejected". I don't want to make this heated but you're framing me instead. I don't think this helps with your point. Especially, as my deletion requests are against my own submitted packages, those are submitter + maintainer's requests, different from a user's request against another user's package.
@7Ji has responded to one of my deletion request at a point when I only submitted a few ARM-related ones. In my response, I provided further links to back up my claim that ARM-only packages are not in accordance with guidelines. I also provided a link to precedent, i.e. one of the deletion request threads pertaining to an ARM-only package, which included @muflone's reasoning for dropping said ARM-only package.
Those who assert that most of my requests are illegitimate are discrediting @muflone most of all, because he is the one who has treated
To make up to the previous point, that was not my package. I replied to that as I was a recently invited co-maintainer for patches I provided to that package. It's also that package's maintainer who mass filed deletion requests to all their packages. the supermajority of my requests. He has so far accepted, by my rough guesstimate, at least 98% or more among those. Are you saying that he is doing questionable and erratic work? I myself do not see that view justified at all. I've never said your previous work was bad / harmful, nor did I disagree with previous PM's decisions. More than so I did not judge any PM. But you're associating your work with PM's and I don't think that's right. It was the requests that are your work, not PMs decisions, and their decisions shouldn't make your work worse/better.
Many of my requests follow similar, considered reasoning for similar cases that are covered by filings from more veteran and well-respected AUR community members like @a821 and @FabioLolix.
I think also that fair treatment is a necessity when one is accused and
I don't want this thread to drag more people in, but since you mentioned them: I agree they are good AUR users and they have a good history of good requests. But similar does not mean same, especially with this quantity and you end up with a template-like requesting style. Just as I'm writing this you closed PRQ#51285 and filed PRQ#51286 to the same package. framed, and such attacks should be called out rather than being tolerated or outright condoned. If AUR staff gives in to such, that would just alienate good-faith members like me. Yes, and why are good-faith members like you have framed me instead as mentioned in the previous point? Please, I don't want this to be heated but you seem to want this to end right away with one side involved getting banned or driven out, instead of letting it go through thorough discussion in the thread. This is not how discussion should go. Yours, 7Ji
I've never said your previous work was bad / harmful, nor did I disagree with previous PM's decisions. More than so I did not judge any PM. But you're associating your work with PM's and I don't think that's right. It was the requests that are your work, not PMs decisions, and their decisions shouldn't make your work worse/better.
If you assert that my requests are all irrelevant and ill-conceived, then logic necessarily dictate that the Package Maintainers who have accepted those in the past are stupid or negligent, which is an implication I find insulting and untrue. And also this is evidence of your own negligence instead when lodging your ill-conceived framing complaint against me. You have accused me of automatically filing mindless requests made by scripts:
I'm against using some self-written scripts to mass-file requests to certain packages just based on their traits, like keywords, names, or whatever.
You have also insinuated that I file requests without consideration:
every request, no matter they're for orphan, merge, or deletion, need to be thought carefully and sent with details associated closely with it. And blindly filing them just adds burden to PMs as this leaves research to be done to PMs.
Regarding my requests asserting a mistaken statement:
The direct reason I want to post this is reading following requests: PRQ#51267[1], PRQ#51269[2], PRQ#51270[3] and PRQ#51271[4], these affects armcl-opencl[5], arm-linux -gnueabihf-armcl-neon[6], aarch64-linux-gnu-armcl-opencl+neon[7] and aarch64-linux-gnu-armcl-neon[8] accordingly.
You should have responded to at least one of the individual deletion request you have objection with instead of using this one point of mistake to add to your framing me on aur-general and furthering your baseless accusation that I am mass filing automated requests made via scripts. I would have amended my mistake quickly. I do listen to relevant feedback and learn from them, and from my mistakes as well.
I don't want this thread to drag more people in, but since you mentioned them: I agree they are good AUR users and they have a good history of good requests. But similar does not mean same, especially with this quantity and you end up with a template-like requesting style. Just as I'm writing this you closed PRQ#51285 and filed PRQ#51286 to the same package.
You are now trying to hold against me my revocation of my own request because I realized a mistake, whereas previously you accused me of filing mindless script request. These are mutually contradictory to each other. But again, I see that you just want to push me into a corner while not taking any responsibility for your exaggerated blaming response in front of all AUR staff and core community members.
Yes, and why are good-faith members like you have framed me instead as mentioned in the previous point?
I have simply pointed out that behind your insinuatons are baseless bad-faith assertions. Is defending my innocence framing you?
I don't want this to be heated but you seem to want this to end right away with one side involved getting banned or driven out, instead of letting it go through thorough discussion in the thread. This is not how discussion should go.
I'm sorry, what banning? Why are you again implying untrue things about me?
It was you who implied that I am some kind of bot whose requests are just a non-useful burden on PM's. Which, if believed to be true, would lead to my banning from this platform, thanks to your hostile action.
This behavioral pattern you are following is called criticism deflection and blame shifting / mirroring. Instead of taking responsibility for accusing me falsely, now you are painting an alternative reality picture about the victim (me) being actually the abuser.
The fact is, for already closed requests of mine, the ones that I didn't revoke, has so far had ~99% acceptance ratio.
Like I said, when filing requests, I add relevant information that should aid the maintainer in understanding the issues, and in case of ARM packages, I copy-pasted a few statements and links that are relevant to the case (pointing to the Arch rule against non-x86_64 compatible packages, and also links to ArchLinuxARM.org forum resources on submitting packages there).
So in essence, you are blaming me for trying to be helpful, and framing that behavior as evidence of spam.
Such communication of yours is intended to flame up the community against me, to drive me out. It is definitely not a way to work with a fellow community member.
I don't hold my experience in the AUR community in very high regard already, based on earlier unfair attacks that I've suffered. I am just too lazy for now to move on to some other community, and I still enjoy the hands-on, no unnecessary hyper-bureaucracy approach here.
But right now I really wish I'd left this toxicity behind.
Yours,
Marcell
On 15 November 2023 16:14:55 GMT+01:00, 7Ji
Please don't frame me with baseless accusations
In followup to that, @7Ji has mass-filed 40+ deletion requests of their own, for other ARM-only packages, and for some other package that are not necessarily ARM only (and @muflone has rejected a few of them because of this). So who is the one who just blindly copy-pastes requests? It's definitely not me.
My whole account just has 11 PRQs, 2 of which are merge, and 9 of them are deletion, all filed against my own packages, all accepted. None of them is "not necessarily ARM only (and @muflone has rejected". I don't want to make this heated but you're framing me instead. I don't think this helps with your point.
Especially, as my deletion requests are against my own submitted packages, those are submitter + maintainer's requests, different from a user's request against another user's package.
@7Ji has responded to one of my deletion request at a point when I only submitted a few ARM-related ones. In my response, I provided further links to back up my claim that ARM-only packages are not in accordance with guidelines. I also provided a link to precedent, i.e. one of the deletion request threads pertaining to an ARM-only package, which included @muflone's reasoning for dropping said ARM-only package.
To make up to the previous point, that was not my package. I replied to that as I was a recently invited co-maintainer for patches I provided to that package. It's also that package's maintainer who mass filed deletion requests to all their packages.
Those who assert that most of my requests are illegitimate are discrediting @muflone most of all, because he is the one who has treated the supermajority of my requests. He has so far accepted, by my rough guesstimate, at least 98% or more among those. Are you saying that he is doing questionable and erratic work? I myself do not see that view justified at all.
I've never said your previous work was bad / harmful, nor did I disagree with previous PM's decisions. More than so I did not judge any PM. But you're associating your work with PM's and I don't think that's right. It was the requests that are your work, not PMs decisions, and their decisions shouldn't make your work worse/better.
Many of my requests follow similar, considered reasoning for similar cases that are covered by filings from more veteran and well-respected AUR community members like @a821 and @FabioLolix.
I don't want this thread to drag more people in, but since you mentioned them: I agree they are good AUR users and they have a good history of good requests. But similar does not mean same, especially with this quantity and you end up with a template-like requesting style. Just as I'm writing this you closed PRQ#51285 and filed PRQ#51286 to the same package.
I think also that fair treatment is a necessity when one is accused and framed, and such attacks should be called out rather than being tolerated or outright condoned. If AUR staff gives in to such, that would just alienate good-faith members like me.
Yes, and why are good-faith members like you have framed me instead as mentioned in the previous point? Please, I don't want this to be heated but you seem to want this to end right away with one side involved getting banned or driven out, instead of letting it go through thorough discussion in the thread. This is not how discussion should go.
Yours, 7Ji
Am 15.11.23 um 15:21 schrieb Marcell Meszaros:
Which clearly won't work with the x86 architecture.
You have clearly not understood how cross compiling works. -- regards, brainpower
On 11/15/23 16:21, Marcell Meszaros wrote:
'armcl' stands for ARM ComputeLibrary. For using ARM-based SoC's and their GPU component for mass parallellized, floating point heavy computation.
Which clearly won't work with the x86 architecture.
How is this just irrelevant and baseless spam?
The AUR submission guidelines didn't really blacklist packages for ARM. Your suggestion about submitting the packages to Arch Linux ARM isn't really an alternative because they don't have an equivalent platform like AUR. I believe that witch-hunting useful ARM-only packages and forcing maintainers to go away sharing elsewhere does more harm than good to the community. Arch may gain more platform support in the future, and how would that be possible without more users involving? AUR was the reason why I started contributing in Arch and I am really disappointed that the current situation is driving contributors away. -- Regards, Felix Yan
Same as GIT packages. archived or not archived, you can still download and you can still build (in some cases). -git vcs packages (or other vcs protocols) is only the method for fetch the contents. is not necessary keep still in developement
this can be applied to old (older than 2023) programs which still works as expected greetings
Hi @felixonmars, thank you for your feedback.
Other AUR Package Maintainers / Developers like @muflone have asserted that packages on AUR should work with x86_64. Also there's a statement to that effect in Arch package guidelines, linked to by AUR submission guidelines, and the latter states that the former shall be applicable in whole for AUR packages as well.
Like I said, and what @jelly have also agreed with, it seems there is room for improvement with respect to the AUR package submission / hosting rules.
I myself also don't oppose ARM packages, but their existence is not supported well by current AURweb, which AFAIK does not support architecture-specific dependency lookup in its webrequest interface, nor does AURweb itself.
Wish the best,
Marcell (MarsSeed)
On 15 November 2023 16:27:53 GMT+01:00, Felix Yan
On 11/15/23 16:21, Marcell Meszaros wrote:
'armcl' stands for ARM ComputeLibrary. For using ARM-based SoC's and their GPU component for mass parallellized, floating point heavy computation.
Which clearly won't work with the x86 architecture.
How is this just irrelevant and baseless spam?
The AUR submission guidelines didn't really blacklist packages for ARM.
Your suggestion about submitting the packages to Arch Linux ARM isn't really an alternative because they don't have an equivalent platform like AUR. I believe that witch-hunting useful ARM-only packages and forcing maintainers to go away sharing elsewhere does more harm than good to the community.
Arch may gain more platform support in the future, and how would that be possible without more users involving? AUR was the reason why I started contributing in Arch and I am really disappointed that the current situation is driving contributors away.
Hi Marcell, I'm not interested in continuing the flame / blame war so I will not response to the previous wall of text. I am curious to understand if you see a problem with you opening thousands of requests in AUR. We clearly stated in many occasions this is not sustainable from our side (Package Maintainers) for various reasons and we suggesting different ways for finding a solution. On 15/11/2023 16:35, Marcell Meszaros wrote:
I myself also don't oppose ARM packages, but their existence is not supported well by current AURweb, which AFAIK does not support architecture-specific dependency lookup in its webrequest interface, nor does AURweb itself.
Here's a good example. Instead of opening requests for these packages, raise a feature request in AURweb to implement such filters in UI / API. Work _with_ the community. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368
Hi Leonidas, Thank you for chiming in.
I am curious to understand if you see a problem with you opening thousands of requests in AUR.
On my side, I don't see any problem with it. But I definitely don't intend to overburden the Arch/AUR staff. I just don't really have insight into what amount is overburdening and what is manageable.
We clearly stated in many occasions this is not sustainable from our side (Package Maintainers) for various reasons and we suggesting different ways for finding a solution.
Yes, and I can appreciate your and your fellow PM's side in this. But frankly, this has been, again, not really a usable feedback for me, because it just seemed arbitrary.
Last year, Morten Linderud also told me that my requests are badly worded copy-pastes with many errors, which initially made me revoke many outstanding requests of mine. But then throughout some months mostly @muflone has accepted most of the remaining ones. So I did not see why my requests were deemed so bad, it felt unfair. In the end, that kind of feedback lost its credibility in my eyes.
But again, I absolutely value fair criticism and usable feedback, and again, I do not want to cause undue burden on anyone. But clearly some benchmark would be welcome by which I can judge what amount is fair and what is too much.
Also, when it comes to PM's responding to requests, I am grateful for all of them who do that. But I also feel that the community, myself included (if I still qualify), is let down by roughly 50-55 Package Maintainers who never seem to engage in this kind of, shall we say, package maintainers' activity.
And then it comes to some PM's just processing new requests and not old ones, and it's just resulted in more old backlog, which for the past 6 months when I was actively paying attention, were almost single-handedly dealt with by @muflone again.
I do see that having to process this many request is a burden, but why is it that most of the others don't participate in that?
What is a pain point of mine is that it seems I am singled out compared to some others who also file lots of very similar quality requests (though not thousands, but "just" hundreds), and they don't seem to he asked to back down, and also do not get such devastatingly negative feedback about the alleged quality of their submissions.
And one more point to that: I believe it is fair to say that it would be a much more credible ask if it were @muflone who made it, because the workload he is taking on is huge. But when others make it who are doing negligible amount of request processing, it just makes me feel it's a bit hollow.
I hope you can understand my subjective side in this topic.
Thank you again for initiating a discussion with me.
Please kindly advise what I shall do with my 2200+ outstanding requests. Should I just revoke them all, or should I try to prune their number down based on some aspect?
Appreciate all your guidance and your valuable work, along with that of all other Arch/AUR developers/maintainers.
Cheers,
Marcell (MarsSeed)
On 15 November 2023 17:58:19 GMT+01:00, Leonidas Spyropoulos
Hi Marcell,
I'm not interested in continuing the flame / blame war so I will not response to the previous wall of text.
I am curious to understand if you see a problem with you opening thousands of requests in AUR. We clearly stated in many occasions this is not sustainable from our side (Package Maintainers) for various reasons and we suggesting different ways for finding a solution.
On 15/11/2023 16:35, Marcell Meszaros wrote:
I myself also don't oppose ARM packages, but their existence is not supported well by current AURweb, which AFAIK does not support architecture-specific dependency lookup in its webrequest interface, nor does AURweb itself.
Here's a good example. Instead of opening requests for these packages, raise a feature request in AURweb to implement such filters in UI / API.
Work _with_ the community.
Cheers,
Hello Leonidas, Sorry if this is off-topic, but since Arch Gitlab is restricting registration I don't have an account to ask there As I want to poke around the aurweb codes and possibly send patches later, I've just fetched the source and dug a little bit. Turns out, based on how aurweb/initdb.py is written, and digging the internal DB after started aurweb for some testing, there's no field for package arch in DB, so adding an arch key to the DB would be a pretty big and perhaps breaking change (Hardly anyone would want and dare to add a column to an in-production table). But if it really is possible, considering v6 API is pending, there might be enough time window to implement the API change alongside DB change. It's kinda a shame I don't really have much time until the end of the year to really work on this. May I ask, when will the v6 API be published? Best regards
On 15/11/2023 17:59, 7Ji wrote:
Hello Leonidas,
Hello, I've changed the subject since this is not related to the thread about requests.
Sorry if this is off-topic, but since Arch Gitlab is restricting registration I don't have an account to ask there
You can ask for an account - please send an email with your desired username in accountsupport@archlinux.org to handle the request.
As I want to poke around the aurweb codes and possibly send patches later, I've just fetched the source and dug a little bit.
I suggest to also join #archlinux-aurweb where the codebase discussion is happening and we can answer questions.
Turns out, based on how aurweb/initdb.py is written, and digging the internal DB after started aurweb for some testing, there's no field for package arch in DB, so adding an arch key to the DB would be a pretty big and perhaps breaking change (Hardly anyone would want and dare to add a column to an in-production table). But if it really is possible, considering v6 API is pending, there might be enough time window to implement the API change alongside DB change.
We can add a column, it's not an issue really and we can run migration scripts automated with a new version release to align all current packages. We might potentially implement some kind of validation as well during the submission of a PKGBUILD to allow certain architectures - will need to do some work on what's the current state of all PKGBUILDs - fun times :)
It's kinda a shame I don't really have much time until the end of the year to really work on this. May I ask, when will the v6 API be published?
Hard to say. Not entirely sure what's missing from v6 at the moment. Cheers, -- Leonidas Spyropoulos Developer & DevOps PGP: 59E43E106B247368
Hi, On 15/11/2023 15:21, Marcell Meszaros wrote:
Hi all,
Again quoting from the mail I am currently responding to:
Getting this automated in AURWeb itself would be a lot more helpful then filling ~ 50k deletion requests.
I don't know where the 50k (50.000) figure comes from. I have filed more than an order of magnitude lower amount of that during the last 3 years. I have also learned from my initial mistakes and now I try to include a little bit more information in each submission. Of course, I also try to be brief if possible.
I have to apologize as I misquoted, we have 2929 package requests found. In total 59 pages, I accidentally quoted all opened requests that was not my intention.
As the AUR has been a low policing zone for most of its existence, with no pre-submission and during-maintenance code review gating, it is inevitable that there is a huge amount of dead weight in it. With older versions of PKGBUILDs still existing when a newer one was already submitted maybe due to VCS repository migration from one type to another, or when one library gets deprecated by upstream in favor of others.
During the last half year, I have focused predominantly on packages that intended to be drop-in replacements of Arch repo packages but which were defunct in one way or another. These packages had the highest exposure to users while still being dead or unneeded, or just plain duplicates, new or old. In consequence of their deletion, people have much lower chance of choosing alternatives that are not proper or viable ones.
My other focus was dead/unneeded Python2 packages and also dead Python3 ones.
Of course I also filed many requests based on the long unavailability of the sources and/or mandatory dependencies. (I usually check web.archive.org as well to get a better picture on how far back the dependencies have been missing.)
Many of my requests follow similar, considered reasoning for similar cases that are covered by filings from more veteran and well-respected AUR community members like @a821 and @FabioLolix. I don't see why my requests in particular would be less valid than theirs, if both theirs and mine have well-founded arguments based on the same kinds of issues that make them choose to file those requests.
We appreciate the efforts to clean up the AUR, as it has indeed accumulated a lot of packages. What I tried to explain is that the current approach is overburdening the team and the sheer amount of requests overwhelms them.
With AUR having 86.000+ pkgbases and still keep packages from 10+ years ago, it is not so outrageous to see thousands of requests filed.
I don't think that sanctioning legitimate community members like me in their legitimate requests is a just and valid solution for a problem that clearly has more adequate ways to handle.
One better way could be to try to involve more PM's amont the 64 in total, with more regularity. Another could be to add issue category tags to requests, like in GitHub/GitLab issues, so that PM's could more easily filter based on those. If such system were in place, prioritization would be facilitated tremendously, e.g. severe security and system integrity violations could be separated from e.g. "unused packages" low-importance housekeeping.
The overall workflow for requests can be improved for sure, that is out of the question.
Orphan requests should also be enhanced, e.g. if lingering for weeks and months without any response by maintainer, any AUR comment by maintainer, and any commit by maintainer, then the should be auto-accepted.
This sounds like a valuable improvement. I thought the AURWeb had some scripts which ran every 6 months to auto orphan old packages but I can't find anything for it.
AUR rules that are vague could also be clarified further, to reduce ambiguity in evaluating the legitimacy of requests.
Agreed. I for one find it valuable to also include ARM/RISC-V packages in the AUR. If we ever want to expand into support ARM that would be very valuable.
There are use cases that are not addressed at all by current guidelines. E.g., AppImage based binary packages and their naming, and also naming Electron based packages that do or do not bundle their own copy of the electron runtime.
In case some AUR packages are kept for extra-AUR applications that are not submitted, the proper solution is to create helper metapackages that hold the needed dependencies, so that the extra-AUR applications can easily be installed and made to work. Otherwise "dangling" libraries with no other packages to use them with just look utterly useless on AUR. AUR guidelines should set this requirement, spelling out explicitly that without legitimate consumers on AUR, many-years-old libraries without any downstream dependents, especially if they are also lacking any or at least a responsive maintainer, are fair game for deletion.
Automated checking systems could also help, though deleting packages based solely on bots' evaluation could also be problematic. (Although some obvious filters could be used for auto-deletion with maybe a deadline, e.g. for using sudo inside the PKGBUILD.)
Uhm, what I hinted at, is maybe a one time script to remove all packages which are not functioning because of a missing source and aren't touched. This can be done by us the AUR maintainers rather efficiently and hopefully foolproof by parsing SRCINFO files. For example: https://aur.archlinux.org/cgit/aur.git/tree/.SRCINFO?h=vim-autocomplpop&id=7484a010ea0b03450695db7976de8631769e6d59#n10 What doesn't work well is filling thousands of requests with which we can't keep up with. It helps a ton if you get the AUR Staff behind your cleanup, then we can help and implement things quickly via automation.
Nevertheless, a human like myself is actually a valuable evaluator when it comes to submissions, despite the hostile and demeaning accusations and classification that I have seen levied against me.
I think also that fair treatment is a necessity when one is accused and framed, and such attacks should be called out rather than being tolerated or outright condoned. If AUR staff gives in to such, that would just alienate good-faith members like me.
I don't read the email of 7Ji as an attack or framing. They raise concerns about the amount of requests you fill. If I look at the requests page now I see 4 within 30 seconds which can give the impression that it is automated, note that they said in their email "script-like" which does not imply it is scripted. Greetings, Jelle
hi, i have been CCed enough times, so i might give my opinion a bit. 2 years ago, when i was spamming deletion requests kinda like MarsSeed, i was asked to stop making deletion requests for packages with broken dependencies because, i was told that, some script would be developed to help to clean up AUR. right after that, my laptop died, and ... at that time, i wrote a script that downloads `packages-meta-ext-v1.json.gz` and checks for packages with broken dependencies. then i would manually review them and file for deletion. but after coming back when i ran the script again, i saw packages with my comments saying they were broken and needed to be fixed... so i guess the scripts are still in development... i would love to help if that's the case. i do understand that spamming arch-request is not the best way to go about it, so i think it will be cool to have an official place for those who wanna clean up AUR to collaborate and build up a list(IRC is the best place for making a list), then file a bulk deletion request. and i think we need much more detailed documentation about where to draw the line about what is allowed in AUR. seems like reality is quite complicated :) e.g. some of my questions Q: Should the library package be deleted if there is no dependency ?? - some people say they might be used in later packages but then how long or ever that pkg be there ?? Q: when is it ok to have ARM-only packages ?? - i do agree with @felixonmars's comment and i sure don't wanna discourage people, what should be done ?? and my biggest question after the last few days of mail exchange Q: is it ok for people like me and MarsSeed to try to find broken/out-of-line packages and file deletion req ?? is it ok to actively seek out and try to clean up ?? i do understand this question's answer might be "depends". but at least i would like to know in detail what's the philosophy about/of AUR. there seem to be many opinions and confusion. so, i will wait for a concrete answer before i test for broken packages. don't forget those are just **opinions** mate and i hope i haven't made anyone disappointed. also sorry for my bad english, if anything confuses you mail me. have a nice day. p.s. i wanna translate archwiki to bangal. if you have any advice, that would be awesome. On 11/15/23 21:39, Jelle van der Waa wrote:
Hi,
On 15/11/2023 15:21, Marcell Meszaros wrote:
Hi all,
Again quoting from the mail I am currently responding to:
Getting this automated in AURWeb itself would be a lot more helpful then filling ~ 50k deletion requests.
I don't know where the 50k (50.000) figure comes from. I have filed more than an order of magnitude lower amount of that during the last 3 years. I have also learned from my initial mistakes and now I try to include a little bit more information in each submission. Of course, I also try to be brief if possible.
I have to apologize as I misquoted, we have 2929 package requests found. In total 59 pages, I accidentally quoted all opened requests that was not my intention.
As the AUR has been a low policing zone for most of its existence, with no pre-submission and during-maintenance code review gating, it is inevitable that there is a huge amount of dead weight in it. With older versions of PKGBUILDs still existing when a newer one was already submitted maybe due to VCS repository migration from one type to another, or when one library gets deprecated by upstream in favor of others.
During the last half year, I have focused predominantly on packages that intended to be drop-in replacements of Arch repo packages but which were defunct in one way or another. These packages had the highest exposure to users while still being dead or unneeded, or just plain duplicates, new or old. In consequence of their deletion, people have much lower chance of choosing alternatives that are not proper or viable ones.
My other focus was dead/unneeded Python2 packages and also dead Python3 ones.
Of course I also filed many requests based on the long unavailability of the sources and/or mandatory dependencies. (I usually check web.archive.org as well to get a better picture on how far back the dependencies have been missing.)
Many of my requests follow similar, considered reasoning for similar cases that are covered by filings from more veteran and well-respected AUR community members like @a821 and @FabioLolix. I don't see why my requests in particular would be less valid than theirs, if both theirs and mine have well-founded arguments based on the same kinds of issues that make them choose to file those requests.
We appreciate the efforts to clean up the AUR, as it has indeed accumulated a lot of packages. What I tried to explain is that the current approach is overburdening the team and the sheer amount of requests overwhelms them.
With AUR having 86.000+ pkgbases and still keep packages from 10+ years ago, it is not so outrageous to see thousands of requests filed.
I don't think that sanctioning legitimate community members like me in their legitimate requests is a just and valid solution for a problem that clearly has more adequate ways to handle.
One better way could be to try to involve more PM's amont the 64 in total, with more regularity. Another could be to add issue category tags to requests, like in GitHub/GitLab issues, so that PM's could more easily filter based on those. If such system were in place, prioritization would be facilitated tremendously, e.g. severe security and system integrity violations could be separated from e.g. "unused packages" low-importance housekeeping.
The overall workflow for requests can be improved for sure, that is out of the question.
Orphan requests should also be enhanced, e.g. if lingering for weeks and months without any response by maintainer, any AUR comment by maintainer, and any commit by maintainer, then the should be auto-accepted.
This sounds like a valuable improvement. I thought the AURWeb had some scripts which ran every 6 months to auto orphan old packages but I can't find anything for it.
AUR rules that are vague could also be clarified further, to reduce ambiguity in evaluating the legitimacy of requests.
Agreed. I for one find it valuable to also include ARM/RISC-V packages in the AUR. If we ever want to expand into support ARM that would be very valuable.
There are use cases that are not addressed at all by current guidelines. E.g., AppImage based binary packages and their naming, and also naming Electron based packages that do or do not bundle their own copy of the electron runtime.
In case some AUR packages are kept for extra-AUR applications that are not submitted, the proper solution is to create helper metapackages that hold the needed dependencies, so that the extra-AUR applications can easily be installed and made to work. Otherwise "dangling" libraries with no other packages to use them with just look utterly useless on AUR. AUR guidelines should set this requirement, spelling out explicitly that without legitimate consumers on AUR, many-years-old libraries without any downstream dependents, especially if they are also lacking any or at least a responsive maintainer, are fair game for deletion.
Automated checking systems could also help, though deleting packages based solely on bots' evaluation could also be problematic. (Although some obvious filters could be used for auto-deletion with maybe a deadline, e.g. for using sudo inside the PKGBUILD.)
Uhm, what I hinted at, is maybe a one time script to remove all packages which are not functioning because of a missing source and aren't touched. This can be done by us the AUR maintainers rather efficiently and hopefully foolproof by parsing SRCINFO files.
For example:
What doesn't work well is filling thousands of requests with which we can't keep up with. It helps a ton if you get the AUR Staff behind your cleanup, then we can help and implement things quickly via automation.
Nevertheless, a human like myself is actually a valuable evaluator when it comes to submissions, despite the hostile and demeaning accusations and classification that I have seen levied against me.
I think also that fair treatment is a necessity when one is accused and framed, and such attacks should be called out rather than being tolerated or outright condoned. If AUR staff gives in to such, that would just alienate good-faith members like me.
I don't read the email of 7Ji as an attack or framing. They raise concerns about the amount of requests you fill. If I look at the requests page now I see 4 within 30 seconds which can give the impression that it is automated, note that they said in their email "script-like" which does not imply it is scripted.
Greetings,
Jelle
-- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat
They raise concerns about the amount of requests you fill. If I look at the requests page now I see 4 within 30 seconds which can give the impression that it is automated, note that they said in their email "script-like" which does not imply it is scripted.
That doesn't sound right. First of all, the AURweb requests page don't show seconds, only minutes. And I'm definitely not that fast! :D I also run web.archive.org and archive.today page savings for those packages and their subpackages / comment pages if there are such, after I file for deletion or merge, and wait for their results before going on to file another request.
Uhm, what I hinted at, is maybe a one time script to remove all packages which are not functioning because of a missing source and aren't touched. This can be done by us the AUR maintainers rather efficiently and hopefully foolproof by parsing SRCINFO files.
For example:
.SRCINFO in itself is not actually a reliable source of information unless auto-generation of it is implemented in AURweb git. Many package owners had hand-edited the .SRCINFO or just forgot to update it before changing the PKGBUILD and committing it.
I don't read the email of 7Ji as an attack or framing. They raise concerns about the amount of requests you fill.
I find it a problem if senior Arch/AUR staff don't see framing and fact misrepresentation as a problem. It is a problem if one is a mere user and on the receiving side of it, especially if they have put a not insignificant amount of effort in good faith to try to clean up the AUR.
As someone who already suffered multiple of such attacks for my good-intended actions, I feel very much let down by the de facto community standards or lack thereof that at least a few senior people here demonstrated towards me.
I hope my honest feedback can help bring forth some understanding about these issues, especially that senior staff should call out flaming behavior not just when it is targeted towards them but also towards other users like me.
Thank you for reading my message, and also for your useful feedback, which is always welcome.
Cheers,
Marcell (MarsSeed)
On 15 November 2023 16:39:24 GMT+01:00, Jelle van der Waa
Hi,
On 15/11/2023 15:21, Marcell Meszaros wrote:
Hi all,
Again quoting from the mail I am currently responding to:
Getting this automated in AURWeb itself would be a lot more helpful then filling ~ 50k deletion requests.
I don't know where the 50k (50.000) figure comes from. I have filed more than an order of magnitude lower amount of that during the last 3 years. I have also learned from my initial mistakes and now I try to include a little bit more information in each submission. Of course, I also try to be brief if possible.
I have to apologize as I misquoted, we have 2929 package requests found. In total 59 pages, I accidentally quoted all opened requests that was not my intention.
As the AUR has been a low policing zone for most of its existence, with no pre-submission and during-maintenance code review gating, it is inevitable that there is a huge amount of dead weight in it. With older versions of PKGBUILDs still existing when a newer one was already submitted maybe due to VCS repository migration from one type to another, or when one library gets deprecated by upstream in favor of others.
During the last half year, I have focused predominantly on packages that intended to be drop-in replacements of Arch repo packages but which were defunct in one way or another. These packages had the highest exposure to users while still being dead or unneeded, or just plain duplicates, new or old. In consequence of their deletion, people have much lower chance of choosing alternatives that are not proper or viable ones.
My other focus was dead/unneeded Python2 packages and also dead Python3 ones.
Of course I also filed many requests based on the long unavailability of the sources and/or mandatory dependencies. (I usually check web.archive.org as well to get a better picture on how far back the dependencies have been missing.)
Many of my requests follow similar, considered reasoning for similar cases that are covered by filings from more veteran and well-respected AUR community members like @a821 and @FabioLolix. I don't see why my requests in particular would be less valid than theirs, if both theirs and mine have well-founded arguments based on the same kinds of issues that make them choose to file those requests.
We appreciate the efforts to clean up the AUR, as it has indeed accumulated a lot of packages. What I tried to explain is that the current approach is overburdening the team and the sheer amount of requests overwhelms them.
With AUR having 86.000+ pkgbases and still keep packages from 10+ years ago, it is not so outrageous to see thousands of requests filed.
I don't think that sanctioning legitimate community members like me in their legitimate requests is a just and valid solution for a problem that clearly has more adequate ways to handle.
One better way could be to try to involve more PM's amont the 64 in total, with more regularity. Another could be to add issue category tags to requests, like in GitHub/GitLab issues, so that PM's could more easily filter based on those. If such system were in place, prioritization would be facilitated tremendously, e.g. severe security and system integrity violations could be separated from e.g. "unused packages" low-importance housekeeping.
The overall workflow for requests can be improved for sure, that is out of the question.
Orphan requests should also be enhanced, e.g. if lingering for weeks and months without any response by maintainer, any AUR comment by maintainer, and any commit by maintainer, then the should be auto-accepted.
This sounds like a valuable improvement. I thought the AURWeb had some scripts which ran every 6 months to auto orphan old packages but I can't find anything for it.
AUR rules that are vague could also be clarified further, to reduce ambiguity in evaluating the legitimacy of requests.
Agreed. I for one find it valuable to also include ARM/RISC-V packages in the AUR. If we ever want to expand into support ARM that would be very valuable.
There are use cases that are not addressed at all by current guidelines. E.g., AppImage based binary packages and their naming, and also naming Electron based packages that do or do not bundle their own copy of the electron runtime.
In case some AUR packages are kept for extra-AUR applications that are not submitted, the proper solution is to create helper metapackages that hold the needed dependencies, so that the extra-AUR applications can easily be installed and made to work. Otherwise "dangling" libraries with no other packages to use them with just look utterly useless on AUR. AUR guidelines should set this requirement, spelling out explicitly that without legitimate consumers on AUR, many-years-old libraries without any downstream dependents, especially if they are also lacking any or at least a responsive maintainer, are fair game for deletion.
Automated checking systems could also help, though deleting packages based solely on bots' evaluation could also be problematic. (Although some obvious filters could be used for auto-deletion with maybe a deadline, e.g. for using sudo inside the PKGBUILD.)
Uhm, what I hinted at, is maybe a one time script to remove all packages which are not functioning because of a missing source and aren't touched. This can be done by us the AUR maintainers rather efficiently and hopefully foolproof by parsing SRCINFO files.
For example:
What doesn't work well is filling thousands of requests with which we can't keep up with. It helps a ton if you get the AUR Staff behind your cleanup, then we can help and implement things quickly via automation.
Nevertheless, a human like myself is actually a valuable evaluator when it comes to submissions, despite the hostile and demeaning accusations and classification that I have seen levied against me.
I think also that fair treatment is a necessity when one is accused and framed, and such attacks should be called out rather than being tolerated or outright condoned. If AUR staff gives in to such, that would just alienate good-faith members like me.
I don't read the email of 7Ji as an attack or framing. They raise concerns about the amount of requests you fill. If I look at the requests page now I see 4 within 30 seconds which can give the impression that it is automated, note that they said in their email "script-like" which does not imply it is scripted.
Greetings,
Jelle
participants (10)
-
7Ji
-
brainpower
-
Felix Yan
-
Jelle van der Waa
-
Leonidas Spyropoulos
-
Marcell Meszaros
-
Muflone
-
Polarian
-
sL1pKn07 SpinFlo
-
zoorat