[aur-general] TU appliance Jens Maucher (defcon)

[Andrei Thorp]

My thoughts...

I'd say that the "install" thing was considered to be a minor
infraction -- but regardless of whether it's strictly necessary, I
would say that conventions are good to follow.

As someone who's been involved in an organization with a very strict
entrance system based on votes, I have one thing to say that I have
learned over the years: The number one thing improves chances of
entrance success is knowing the people who are voting. If they know
you and like you somewhat, they are greatly more likely to vote you
in. Look at it this way: even if you're a mediocre packager, but
everyone knows and likes you, then they're likely to think, "Well,
okay. He'll stumble a bit and we'll have to clean up some stuff, but
he's a good, hard-working guy and he'll learn."

As others here have said, this is just most crucial. To paraphrase
above: "Since we don't know the applicant, we have to rely on his
PKGBUILDs. They aren't excellent, so there were a lot of negative
votes". (Mind you, I'm not a TU.)

So here is my recommendation: Now TUs know you somewhat, that's good.
They've seen your name. Hang out with them on IRC/forums/newsgroups.
Be helpful and humble, willing to learn. Then in three months (which,
Iirc, is the time between TU apps), you can give it another shot.
Chances are, if you've been active + nice + improving over that time,
the TUs will know you and probably like you. They'll see that you've
put three months of effort in after being rejected initially, and that
shows dedication and hard-workingness. Chances are, at that point, if
you re-apply, you'll get in without much trouble and be hailed as a
good addition to the team who's overcome adversity and improved
himself.

Good luck,

-Andrei "Garoth" Thorp

On Sun, Apr 5, 2009 at 8:25 AM, Ali H. Caliskan
<ali.h.caliskan at gmail.com> wrote:
> Allan, you're right about your views, but unfortunately, zattoo seems to be
> installed that way, so much for several contributors effort in this
> inconsistency. However, I'll reconsider your critical approach when chaning
> zattoo PKGBUILD.
>
> One thing, mkdir is not something bad to use, I use it all the time, and
> install isn't also not required, since the developers of install command
> argue that a package manager should be used instead of install, so what's
> the big deal here? I mean as long as the code is working, why should it be
> that much trouble to maintain a package. Are we code "fascists" here?
>
> /ali
>
> On Sun, Apr 5, 2009 at 3:25 PM, Allan McRae <allan at archlinux.org> wrote:
>
>> Ali H. Caliskan wrote:
>>
>>> I don't think zatoo should be that much criticized, it looks somewhat
>>> clean.
>>>
>>>
>>
>> I am going to be fairly blunt here, but essentially you are wrong....
>>
>> e.g.
>>
>>  # Kerberos libs
>>  ln -s /usr/lib/libcrypto.so libk5crypto.so.3
>>  ln -s /usr/lib/libkrb5.so libkrb5.so.3
>>  ln -s /usr/lib/libkrb5.so libkrb5support.so.0
>>  ln -s /usr/lib/libgssapi.so libgssapi_krb5.so.2
>>
>>
>> Symlinking libraries to different sonames is, in my opinion, the single
>> worst thing you can do to your install.  It can create bugs that are
>> incredibly difficult to track down.   The current libkrb5.so is .25!  A lot
>> has changed since .3...  The correct way to deal with this is to find a
>> version of the package that supplies these library versions and build it,
>> either within the package or as a dep for the package.  The former is
>> probably cleaner in this case unless something else requires these versions.
>>
>> There is also the use of "mkdir" and "cp" instead of "install" to improve.
>>
>> As Jens pointed out, he no longer maintains this.  But at this point, that
>> is moot.  He maintained it when he applied and the TUs did not know him very
>> well in general so we needed to rely on his packaging skill to judge his
>> application.  The consensus opinion of the TUs was obviously that his
>> package standards were not high enough and I have no doubt that this package
>> was primarily to blame.
>>
>> So, for future reference, here is my subjectiveview of what should have
>> happened after this package was pointed out as bad:
>> 1) a reply to aur-general saying "I will look into it".  If it was fixable,
>> good.  If not then...
>> 2) a reply saying, "This is very difficult to fix.  I am discussing this
>> with my sponsor.  Any suggestions on how to improve it?".
>> 3) possibly delaying of voting until it is shown that the issue is fixed.
>>
>> I see the ability to know when you have a bad PKGBUILD or other problem and
>> then asking for help to be far more important than the ability to produce
>> perfect packages.  Remember, once someone is a TU, they will be providing
>> the community with binary packages.  It is essential that the Trusted Users
>> ensure any new applicant is up to standard.  Any doubt is enough to say no.
>>
>> Allan
>>
>>
>>
>>
>