[aur-general] TU Meeting

[bardo]

On Mon, Dec 1, 2008 at 2:20 AM, Allan McRae <allan at archlinux.org> wrote:
> - bardo drunk too much wine and was having difficulty spelling.

You could have left out this point ;-) But you know... wine is for
intellectuals... maybe.

> A bit more detailed summary:
> - There was some agreement that there appears to be a lot of packages with
> low usage in [community]
> - There was lots of disagreement about the validity various popularity
> measures (pkgstats, AUR votes).
> - No better method for assessing popularity was proposed
> - Restricting entry to [community] based on "popular usage" was discussed
> - A few do not like the idea of restricting TUs packages
> - The definitions of "popular" are hotly debated
> - A proposal for new rules for packages entering [community] will be posted
> to the aur-general list for more discussion
> - A separate proposal about removing low usage packages from [community]
> will be made at a later date.

All the previous points can be summarized in few words: "we agree that
we disagree".

> - It was proposed to add a safe flag on TUs packages in the AUR to encourage
> TUs to leave packages out of community while still being marked in a way as
> they are known to be good PKGBUILDs

I missed this part... luckily. Safe flags were happily killed with a
few months ago. If you mean to add them to [community] packages only,
then it doesn't make sense to me: to make a TU you don't just need the
User, you also need the Trust. Either you don't T the U from the
beginning (and s/he doesn't get elected) or you T, and then you don't
need to flag anything. If someone notices an anomaly in a TU's
PKGBUILD quality, it should readily be reported to the list to take
action.

> - Improving the community backend to reduce server load is being discussed.

This is a very important point, IMHO, which we need to discuss with
the AUR2 guys. In fact I think we could, as we say in Italian, "catch
two pigeons with one broad bean" :) and plan the backend changes to
include the move to SVN. Personally, I'd like to see an independent
RCS layer so that we won't see this situation again when we need to
move to $ZOMGCOOLRCS.


Corrado