Hello,

I have no powers to decide, so take the comments as just my suggestions as far as an appropriate approach:

I am the same here, just wanted to make a few comments after looking into the situation.

1. is it ok to file deletion req for not orphan also not out of date package ??

Deletion requests should not be overused, the following reasons are what you submit deletion requests for: - If a package has been packaged within the official repositories, source and binary/redistributable packages should not be in the AUR, but DO NOT submit ones against VCS packages, these are still valid even when the software is packaged within the official repositories. - If a package breaks copyright laws, this is mainly done if you are the copyright owner, submitting it on the behalf on others is generally unadvised and has caused friction in the past. In this case you really should discuss this with a package maintainer and see what they think, #archlinux-aur on https://libera.chat is the best way to do this. - If a package is not packaged for Arch Linux, for example if someone submits a package designed for Artix (uses OpenRC), AUR is for Arch Linux packages only. - Possibly if upstream abandons development for the package, however this is only sometimes, there are many cases where old packages are still used despite the software being abandoned, so in a general case do not bother submitting deletion requests for these. - If the package is a "subpackage" of sorts depending on a package which has been deleted, for example say we have "foo" and it has a plugin called "bar", if "foo" is deleted, "bar" should be as well. I might have missed a few edge cases, but that should give you a general jist of what you should and should not be reporting. If a package is outdated, and there has been no response from the maintainer, then you submit a orphan request. If a package is a duplicate, submit a merge request, in some cases deletion requests might also be used to counter duplicates.

if he does not update, should i file req then ??

If you have contacted the maintainer, and giving them a decent amount of time to respond, and they haven't responded then you should submit an orphan request. If they do respond and explain they are busy or away for a week or two, do not submit a orphan request, it will only cause drama. If they do not update it for months despite saying they would, then it might be a good idea to submit a orphan request. But in general, if you want faster updates, submit a patch and then show that it is testing and working, the latter is important because bumping pkgver is easy to do, it is testing and ensuring it still builds and has the right dependencies which is important and time consuming.

if he does not update, should i file req then ??

You can always use the comment section for the package to contact the maintainer, but it is advised for everyone to provide contact emails, whether that is leaving it exposed on their aurweb account or putting it as a comment at the top of their PKGBUILD's. However, it is not mandatory.

If the maintainer cannot be contacted (e-mail no longer works, not recent correspondence in the list-archives with a new e-mail, etc..), then there has to be some way to handle their packages.

See above.

2. should AUR host out-of-date but working packages ??

This happens all the time, there are tons of orphaned packages which are out of date and not actively updated, hence being "orphaned". These shouldn't be deleted simply because nobody is maintaining them, instead people are meant to adopt them. Maybe instead of trying to delete everything which is unmaintained you should start adopting it and then maintaining it?

There is always a sliding-scale of "How out-of-date?". Is some user of the package just flagging it 10 minutes after the latest upstream change?

Is a dependency no longer supported by Arch (that's what AUR is for...)?

Some packages may not have been updated in quite a while, but may be 100% valid and still good.

This is hard to give advise on without knowing more about what you are considering "out-of-date"?

My comment to 1. would apply here too.

David, I believe they meant should orphaned old packages be deleted for not being up to date and not actively maintained, if so see above. If I am wrong, feel free to correct me Zoorat.

3. is it ok to ask people to be co-maintainer for their pkgs ??

Yes, you are more than welcome to ask this. However most people do not want random people pushing changes to their packages, and it can cause conflicts between the local changes and remote (AUR), in general its better to email a diff/patch to the author, but everyone has their own way. Github is also common, I see this is what you use, people are able to submit PR's to make changes. Personally I use my gitea instance (https://git.polarian.dev/AUR), but I am not sure if I will continue to do this. The issue with Github/Gitea is third party data collection, Github stores large amount of information on the traffic to the site, which is privacy invasive and unfair for users, and as for my self hosted instance people either use Github SSO which has the same problem as Github, or they have to provide an email and password to create an account. In general, a lot of people prefer diff in comments (I believe this is discouraged by package maintainers, but I can't fully remember) or emailing a patch. This means that there is no privacy concerns. It literally is "whatever floats your boat", but do be mindful of others.

4. review my PKGBUILDs, please list: https://aur.archlinux.org/packages?K=zoorat&SeB=m

A lot of the packages seem fine, and follow the guidelines published on the ArchWiki (some of the guidelines do need updating however). There is a few things I did notice: - https://aur.archlinux.org/packages/mawk -> strip, emptydirs and zipman are all default options in both the default makepkg.conf and the devutils makepkg.conf (which is used to build official packages), the options here are redundant, in general you should let flags be declared in makepkg.conf unless it is mandatory for the package to build, otherwise you are taking away the configurability. - https://aur.archlinux.org/packages/fluent-reader-bin -> Package is an appimage (well extracted one), I have not checked upstream but if a binary executable is also given, this name should be changed to have the suffix "-appimage" so that the redistributable can have "-bin". strip, emptydirs and zipman are also un-needed, see above. - https://aur.archlinux.org/packages/ttf-twemoji-color -> "TwitterColorEmoji-SVGinOT-Linux" is repeated constantly, although this is personal preference, I would define "_name=TwitterColorEmoji-SVGinOT-Linux" and then use "$_name" it makes it so much easier to read, but this is opinionated and not an objective fact. strip, emptydirs and zipman also un-needed, see above. - https://aur.archlinux.org/packages/python-torrequest -> strip emptydirs and zipman un-needed, see above. "setup.py" should be avoided, if it is possible migrate, this depends on upstream (https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_(...)). - https://aur.archlinux.org/packages/parse-torrent -> Node.js library without anything depending on it? There is no binary installed to /usr/bin so I assume this must be a library. Also again, strip, emptydirs and zipman are un-needed, as they are default, see above. - https://aur.archlinux.org/packages/betterdiscord-installer-bin -> appimage, if betterdiscord-installer upstream also provides a binary redistributable, this should be renamed to betterdiscord-installer-appimage so that the redistributable can be packaged. Also again, strip, emptydirs and zipman are un-needed, they are default, see above. - https://aur.archlinux.org/packages/faq-bin -> Little nitpick, it could be "Maintainer", "Co-maintainer" or "Contributor", "Original submitter" is unconventional and annoys me a little, others may agree/disagree, but normally sticking to them 3 is sufficient. Also strip, emptydirs and zipman are un-needed, as they are default, see above. - https://aur.archlinux.org/packages/mymonero -> Source package name which is actually an appimage, should have the suffix "-appimage", or I believe "-bin" is valid too, but should be avoided in case of there being a non-appimage redistributable (tarball for example). Also again, strip, emptydirs and zipman are un-needed, as they are default, see above. Also you do not need "provides" here, as this is implied by makepkg, well for source packages, it will be required once renamed to a non-source package (VCS or binary package require provides/conflict options). - https://aur.archlinux.org/packages/webtorrent-bittorrent-tracker -> provides and conflicts not required, these comments can be removed safely. strip, emptydirs and zipman are un-needed, as they are default, see above. - https://aur.archlinux.org/packages/nodejs-autocannon -> strip, emptydirs and zipman are un-needed, as they are default, see above. Furthermore, provides/conflicts is not needed as this is a source package. - https://aur.archlinux.org/packages/docker-systemctl-replacement-git -> conflict/provides needed, conflict and provide docker-systemctl-replacement. - https://aur.archlinux.org/packages/nodejs-clinic -> conflicts/provide is not needed for a source package. strip, emptydirs and zipman are un-needed, as they are default, see above. - https://aur.archlinux.org/packages/ezshare-> conflicts/provide is not needed for source packages, the comments can be removed. strip, emptydirs and zipman are un-needed, as they are default, see above. - https://aur.archlinux.org/packages/opencomic-bin -> strip, emptydirs and zipman are un-needed, as they are default, see above. As a general note, "glibc" does not need to be specified as a dependency as it is within the "base" package, and thus installed on system, it doesn't hurt to specify it however. I only briefly looked through each of the packages, this is in no way an indepth analysis, it already took me a good hour to look though each one above, I suggesting specifying specific ones you want checked indepth instead of the long process of checking each one. I hope the advice above helps, for others, if I missed something or made a mistake, please correct/add more suggestions to what I already specified.

5. about TU ?? my 1224 deletion req was accepted, and 6 deletion req was rejected, 52 req is pending for now. (got this number by filtering by `notify@aur.archlinux.org` and searching for "has been rejected by" / "has been accepted by". don't know if it's right info tho) and i'm also maintaining some pkgs. is this enough ?? when i asked last time, @ainola told me my account was young. do i meet the requirements for being a TU ??

I will be brutally honest here (please do not take anything I say as a personal insult), although I am a regular user, I will explain how this works (You could also read: https://wiki.archlinux.org/title/Package_Maintainers#How_do_I_become_a_Packa...). The TL;DR is you don't pick to become a package maintainer (TU is deprecated term), you are chosen for your contributions, see below for a more indepth answer. Package maintainers (formerly TUs) are picked based on their ability, dedication to the community, and maturity. All 3 is important. package maintainers are picked on a case-to-case basis, when eligible (aka wanted) you will be offered a sponsorship from the amazing people who maintain the official repositories, when you get 2 of these you can apply by sending a GPG signed email to the mailing list explaining who you are, what you have done for the community, and who sponsored you, there are tons of examples, for example Antiz and gromit both were voted in this year, I remember them applying :P (congrats again to both of you) Maintaining a few packages isn't generally enough, have you submitted bugs? have you tried joining the Arch Testing Team and testing packages and submitting issues, or even patches to the packages to fix them? Your account might not be young, but you have disappeared for a year... you can't just leave for a few years pop back and say "look my account is old now". Every package maintainer put ridiculous amounts of time into their role before they were even considered. But say you got outstanding activity, do you have the skill? Have you showed the ability to package pragmatically? Most of your packages are very straight forward and easy to follow the guidelines, but this is not always the case. Also bragging about the number of deletion requests accepted feels wrong... deletion, at least in my eyes, is a last resort, in most cases you want to orphan or merge, why not go through the orphans and go shopping, pick up some packages you are interested in and maintain them, build your skills in other words? Its very childish to say, "hey I maintain a few packages, and my account is older now, can I have a job", something I learnt to ask myself is "Why should I be picked?", and yes when I ask myself that in the context of becoming a package maintainer its "hell no". There is the idea of "those with skill, do not need to prove they are skilled". If you are constantly asking "am I eligable yet?" the answer is most likely no. It brings up the question of do you have the right morals to become a package maintainer... being so desperate for a roll shows greed, if your reason is like most peoples which is wanting to contribute to Arch Linux, you do not need to become staff to do this. Sure being a staff member makes it easier and you get more toys to mess with, but you can do so much without being a package maintainer (unless you are moderated). In other words, stop trying so hard to become a package maintainer, and focus on actually contributing, the rest comes later. For example, I can use gromit as an example here, he was everywhere in the community, he was helping people constantly in the channels, and also was always there for a chat with the community, I never saw him once have to ask... to my knowledge he was approached and offered, and of course he accepted. (gromit correct me if I am wrong :P) Heres some suggestions, I can't say "it worked for me" because I am not a package maintainer, but other package maintainers did the same and they eventually were picked: - Join the Arch Linux Testing Team (see: https://wiki.archlinux.org/title/Arch_Testing_Team), join #archlinux-testing to apply, do not email. - Adopt orphaned packages within the AUR. - Submit patches to fix AUR packages, or even official packages. - Help people in #archlinux and #archlinux-aur - Join #archlinux-offtopic to get to know people (if you like, this one is subjective to the type of person you are) - Contribute to conversations on the mailing list (for example when I search our email I get little - Contribute to ArchWiki (https://wiki.archlinux.org), packages are useless if there is no documentation on how to use and configure them :) - Submit patches to Arch Linux codebases (https://gitlab.archlinux.org) - Be mature, active, friendly and kind. Then just sit back and wait, by the time you are offered you probably will have forgotten all about it.

6. shouldn't i remove inactive co-maintainers ??

You are the Maintainer, it is up to you. In general I would say yes, but others might think it would be rude. I strongly advice joining (and bouncing) #archlinux and #archlinux-aur if you are passionate about contributing. #archlinux-testing if you want to become an Arch Linux Tester, and then #archlinux-wiki if you want to contribute to the wiki. Anyways, I have wrote a lot, and I have spent way too many hours doing so, but I hope there is at least some usual information here for you :) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@icebound.dev