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 <je...@vdwaa.nl> wrote: >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
