Am 22.01.2014 23:56, schrieb Balló György: [...]
2014/1/22 Xyne <xyne@archlinux.ca>:
I don't want to discourage you from further contribution but I do not think that you are ready to be a TU. You should take some time to address the issues raised in this thread and then spend at least a few more months maintaining your packages. Orphan some if you cannot adequately manage all of them. Quality counts for far more than quantity. [...] I agree with Xyne. You have to learn some more things and clean up your packages before you are ready. [...]
After reading this thread I want to add something that bugged me (arch power user for 4 years) for quite some time now: When is the time someone is "ready" to be a TU? Maybe at some point I or others intend to become one as well... I mean yes, there are some information on the Wiki[1] and the minimum requirements say clearly "maintain a few packages in AUR with clean, high-quality PKGBUILDs", which is what was already mentioned in this thread a few times. But as I roam the AUR nearly every day, I often see PKGBUILDs, that are maintained by TUs and not "clean, high quality". Most of them are older than 2 or 3 years, but there are also exceptions. Short excursion: Lets take for example the TUs speps[2] and Dragonlord[3] (picked at random, no offense, we all have skeletons in the closet): speps has ~650 packages, ~50 marked as outdated, thats both quite a few. Dragonlord has ~250, 6 marked as outdated. Also a lot of packages that have fixes, patches or improvements in the comments for months or _years_ for both of them. We have 2014 now, pacman/makepkg changes that deprecate PKGBUILDs without build() function, "|| return 1" and stuff have been there since the mid of 2010. Now, lets filter it a bit using ack[4]: In the AUR git mirror (I know this is not representative, but I did not want to scrape the AUR website) are 734 packages, that have speps in a Maintainer tag, 30 are missing a package() function, 17 have return statements. There are 210 packages, that have dragonlord in a Maintainer tag, ~40 with return statements and ~50 without package() function. I know there are some false-positives, but bear with me. Dragonlord sometimes only adds himself to Contributors rather than Maintainer. Also there are packages with new maintainers forgetting to change the tag. This cases are not easy to parse though. There are also a lot of packages that do not use quoting for $srcdir and $pkgdir, but this is just bad practice, not wrong per se. If I look further there are a lot of PKGBUILDs with the old way of checking out sources in VCS, this feature is available since pacman/makepkg 4.1, considering this is available for more than half a year and the TUs _should_ set good examples for others to follow, this is also not like it should be. You do not have to believe my numbers, just randomly choose some packages and see for yourself. End of excursion, back on topic. I think onny *can* be a good TU as well, as long as he learns from the problems that have been pointed out. He will likely learn from the others as well and get better in time. @onny: Discussion period is not over yet, hurry up and fix/orphan the packages you maintain and your chances will increase. @speps and all others with too many packages to maintain themselves: *Just orphan* packages you do not actually use or want to maintain. For you it is just one click in the AUR webinterface, but others will be hindered in fixing them. What is the reason to have packages that are marked out-of-date and broken for months[5] and years[6]? I do not get it. Fire and forget, maybe? closing words: I know this reads in parts like a rant, but it is just to show you that also current TUs are not better in some aspects. Again it is not meant to blame speps (but seriously, just orphan some packages! :P) or Dragonlord. Just my two cents. best regards, carstene1ns [1]: https://wiki.archlinux.org/index.php/Trusted_Users [2]: https://aur.archlinux.org/packages/?K=speps&SeB=m [3]: https://aur.archlinux.org/packages/?K=Dragonlord&SeB=m [4]: http://beyondgrep.com/ [5]: https://aur.archlinux.org/packages/lib32-freealut/ [6]: https://aur.archlinux.org/packages/skencil/