[aur-general] TU Application - Seblu

[Xyne]

> that means that you don't trust the arch maintainer judgment?  

/snip

> > >> >>But if I want to be a good maintainer, I do understand the reasons.
> > >> >>
> > >> >>and **The trust does not exclude the audit.**

+1

Everyone can make mistakes, even Arch packagers. Ffs, Allan's a core dev :P
More shocking news at 11.




> > >> >Excuse me for asking but is there anything preventing you from moving
> > >> >cairo-xcb to community if you become a TU?
> > >>
> > >> Yes, us.

Who's "us"?


> > >> >As far as i know if you become a TU you can maintain anything you want
> > >> >that has more than 10 votes in the AUR.
> > >>
> > >> Becoming a TU means that you become a member in the developement team, a
> > >> team in which we trust each other, respect each other decisions, use the
> > >> same packaging standards, the same tools as developers etc.
> > >
> > > I think if the package meets the guidelines then you shouldn't bully
> > > someone into not maintaining it. As long as he's providing the support
> > > that should suffice. Sometimes we may need to adjust the guidelines, and
> > > we decide this as a group through a formal vote.

+1 for discussion and voting, -1 for "because I said so, noob".

> > 
> > Seriously? Since when is adding a package that is already in the repos
> > with a different configure flag a good idea? We don't even allow this
> > in the AUR...

I think there's been a misunderstanding. The package would have a different
name via the suffix to indicate the option, which is permissible in both
[community] and the AUR.


> Seriously. While it's not ideal, it has been done.
> I would consider it the same as including bin/lib32 packages just to
> include things like wine or whatever. The [community] repo is intended
> for this kind of experimentation and freedom.
> 
> I think awesomewm has enough of a user base to justify such measures if
> a TU is willing to maintain it.

I mostly agree.

The Arch ideal is to include the most vanilla package possible and let users
compile their own custom packages if they need or want them, but if there is a
considerable demand for non-vanilla build options then I see no reason not to
either change the "vanilla" package or include a clearly labelled alternative
package. As already stated, this has been done before and it isn't a big deal
at all.


> I'm starting to get a bit peeved with people confusing [community] and
> [unsupported] with the [core] and [extra] bits.

Well, now that [community] is official, the line between it and [extra] is
slowly being blurred, maybe even erased, so there's not much reason to be
peeved about the confusion.

I really don't see much difference in the types of packages included in either.
I suspect that some devs treat [extra] as though it were [community] and that
there is no strict policy in place to determine what belongs there and what
belongs in [community].