To become a TU, or not to become a TU, that... is my dilemma.

Question

In spite of my efforts on maintaining packages that I feel benefit the Arch community, and also in spite of my blunders that make me feel helpless, I'm considering whether or not to become a trusted user. I read the prerquisites and I believe I have completed all but one prereq -- basic shell scripting -- which I learn bit by bit. The incentives to WANT to become a TU would be to be able to fix my frequent mispackaging (I'm an unfortunate dummy who sometimes finds a problem that nullifies the package's usefulness after submitting it) than have to take time from the existing TUs via mailing list to clean up my messes and have guilt smack me like a brick. I want people to know, however, that I spend a lot of time (almost 100 packages maintained, minus my mistake packages) testing what I package and finding a solution to a problem, even if I impulsively submit a potentially problematic package, and I do this so much I consider my AUR activity a productive hobby that can consume a few hours every day... or a lot if I'm really hopeful that a certain fix will be "that one fix" that fixes my doozy.
Aside from fixing my own blunders, I do check the mailing list, not just for confirmations to my own requests, but to see if I can lend a hand in picking up other packages (if I know anything about them). As a TU I'd be happy to take on the responsibility of merging/removing requests if they are reasonable. I also have noticed a few AUR packages that have dozens (and in some cases, hundreds or even thousands) of votes, yet continue to be overlooked for transfer into the community repo. I can guess that likely, there's a TU voting process or TU discussion on these matters, but I definately want to give more AUR maintainers a voice in said matters. I can say that, even now as a regular AUR user, I never have had malicious intent and only seek to provide other users with the packages I hope they will utilize.
On the other hand, reasons not to become a TU... well, if I do apply, I want to make clear my strengths and weaknesses. If I get the choice of which packages to administer, that puts me in a position of duties I'm comfortable with and will likely be able to handle, but if it's on an assignment basis, I know I wouldn't be able to do these tasks because I'd likely be assigned something outside of my capabilities. I check the AUR all the time out of necessity as an Arch user, so inactivity would be rare from me.
Thank you for reading.

Answer 1

Wow... I'm honored Sven! Thank you!
UPDATE: Well I've done a lot of cleaning up on my packages (so far), including but not limited to:
* Quoting most directory paths and URLs, with an exception to those containing {} or wildcards
* Downgrading cross packages to reflect the official repo (with an exception to mingw32-gc where 7.1 fails compile whereas 7.2alpha6 succeeds)
* Modified mingw32-* packages to conform to ArchWiki's MinGW PKGBUILD guidelines
=> Description reflects official repo package's (if applicable) with "(mingw32) suffixed
=> Properly unset LDFLAGS variable
=> Properly add !buildflags option
* Removing "|| return 1" and $startdir from PKGBUILDs, replacing $startdir/pkg and $startdir/src with $pkgdir or $srcdir appropriately
* Removing --build=$CHOST from mingw32 autotools PKGBUILDs as I felt they were redundant with --host=/usr/i486-mingw32 having already been supplied
* Modified mingw32-* autotools and CMake packages to create and use a 'build' directory for output
* Modified mingw32-* autotools packages by giving each configure script argument its own line
* Removed the MINGDIR variable from mingw32-* PKGBUILDs and replacing them with a more conventional means of install prefix
* Added noextract to a few packages for CraftBukkit, since JAR files usually are the product, not the archive containing the product
* Renamed fpc-*-*-lcl packages to lazarus-*-* in response to a criticism I found reasonable
* Added optdepends to mingw32-allegro and mingw32-allegro4
* fpc-multilib now properly symlinks ppcx64 to /usr/bin and the utility binaries are no longer 32-bit
Anyway, I'm not done yet but it's 3:30 in the morning and I need sleep.
Last edited by Schala (2012-03-10 17:17:32)