> 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: > >https://aur.archlinux.org/cgit/aur.git/tree/.SRCINFO?h=vim-autocomplpop&id=7484a010ea0b03450695db7976de8631769e6d59#n10 .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 <je...@vdwaa.nl> 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: > >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
