2007/5/9, Calorì Alessandro <axelgenus@gmail.com>:
Il giorno Wed, 9 May 2007 17:08:24 +0300 "Roman Kyrylych" <roman.kyrylych@gmail.com> ha scritto:
To become TU you need only to post short introduction message to tur-users ML. The procedure of becoming a TU is not that hard, really (though, I must confess I was a bit scary to write my introduction :-) ) BTW, what's your AUR login?
I'm an Arch user from just about 1 month and an Arch64 user from two weeks but I'm a linux user since 2004... my nick in AUR is "axelgenus".
However, I read the "requisites" to be a TU and they are somewhat discouraging... I mean:
1) maintain packages on community repo, yes of course but what packages? The best and more useful packages are owned by TUs... Now I'm writing a PKGBUILD for Neverwinter Nights' linux client but how many people will find it useful? It needs to download about 1GB from the bioware server (client + game resources).
2) be well regarded by the comunity... ok, that's obvious but how can I achieve this? I've been a Gentoo user for 2 years and I can't remember just one nick of the people who helped me on the forums... I hope italian users like me find the translations I'm going to do on the wiki useful.
3) be prepared to stay six months in the TU position... I've never made such long-term programs! If I become a TU is because I wanted to... why should I be forced to stay in TU position?
Hmm, I cannot find such text anywhere. Where did you read this? In fact, in order to become a TU nothing of the above is required. TUs should just know that you have enough skills for package building, porting and fixing (applying x86_64 specific patches etc.) and to vote "yes" for you. Having some packages is not _required_, there are other ways to show your skills. You can find a sponsor before or after the introductory message to tur-users ML (usually someone volunteers to sponsor a candidate). If at least one TU (your sponsor) finds you a good candidate, the discussion period and voting procedure begins.
That could be also archieved by offloading many uncommon packages to Community repo.
That's a great idea but I would like the package in community repo to be assigned both to the maintainer and the contributor. Example: I write the PKGBUILD for the program "foo"; if it's moved to community I can't continue to maintain the package because I'm not a TU. This only adds more work to TUs! That's about CVS/SVN/whatever access rights. Also, often a package in unsupported has many contributors over time, because people orphan and readopt it. You can send updated PKGBUILDs to maintainer directly or post in comments. Posting PKGBUILD as a comment (after TU adopted it) doesn't differ much from uploading new version to unsupported (before adoption).
On the other hand it would be very good if some existent TUs become devs (and give out their packages and switched to maintaining official repos only, to reduce workload).
I don't actually know how are devs and TU organized yet but I can suggest you one thing: as I said before it would be very useful if a contributor can maintain a package after it's added to the community repo. The maintainer should only watch over some contributors revising their work.
See above. BTW, there are cases where non-devs/non-TUs send updated patches that devs/TUs just review and commit to CVS.
However: why packages are builded manually? Can't they be builded automatically on some dedicated servers (at least one for each arch).
Pacbuild is on the way. -- Roman Kyrylych (Роман Кирилич)