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

[Ali H. Caliskan]

We'll as long as there is no human factor in stake, I believe making a
package, especially a community package isn't that much a security risk. We
are not talkling about "core" or "extra" packages, just the community repo,
which is of course provided by the community users. I'm sure that the the
Arch Linux user would understand that. Also, one will eventually grow into
such responsibility and organization. So the filter process should be
efficient and smart, not inconsistent. This is my point of view, so good
luck guys with your hard work :)

On Sun, Apr 5, 2009 at 10:24 PM, Jaroslav Lichtblau <tu at dragonlord.cz>wrote:

> On Sun, Apr 05, 2009 at 10:13:03PM +0200, Baho Utot wrote:
> > Ali H. Caliskan wrote:
> >> Well there is a difference between TU and developer, I'm not saying that
> >> it's not required to be good at coding and consequent about organizing a
> >> PGBUILD, what I'm saying is that we should embrace the enthusiasm and
> >> dedication by people who want to contribute and serve the community the
> best
> >> way they can. So the requirements should be much tougher as developer
> than
> >> TU. Please reconsider Jens as a TU, not as what he *is*, but what he can
> *be
> >> *. Que bono?
> >>
> >> /ali
> >>
> >> 2009/4/5 Angel Velásquez <angvp at archlinux.com.ve>
> >>
> >>
> > Yes, I think anyone could be an asset.
> >
> > Why is the TU all about making packages/being a good packager?
>
> It is not just about to be a good packager. But as said before, you
> have the power to create binary packages and access the [community]
> repository, and we need to be sure that TU's know what they do.
> This is my point of view.
>
> >
> > For me I am good at making bugs, so I could never be a TU but I could be
> > a TBM (trusted bug maker) :)
> >
> >
> > [putloin]
> >
>
> --
> - No manual is ever necessary.
> May I politely interject here: BULLSHIT.  That's the biggest Apple lie of
> all!
>        -- Discussion in comp.os.linux.misc on the intuitiveness of
> interfaces
>