[aur-general] Official discussion period - Rules governing packages entering [community]

[kludge]

Aaron Griffin wrote:

>> My succinct conclusions:
>> . Everybody agreed that we weren't able to find a statistically
>> relevant way to calculate package usage.
>> . Imposing limits, albeit relaxed, on TUs will, in my opinion,
>> demotivate many of them. I'll be the first to feel demotivated.
>> . We are using as a reference the pkgstats results that came from very
>> few days of usage. If we really want to put arbitrary limits, then
>> they should be discussed after *at least* one month of pkgstats
>> running. I already wonder: did results change from when we started the
>> discussion?

<snip>

>> better exploit the mean of voting, and get more useful numbers.
>> . Don't put any hard limits at all, just encourage contructive
>> discussion and communication between TUs themselves, the community and
>> devs. I personally trust all of you TUs and I think that, by better
>> defining what our goals are and how we want our repo to be, we can
>> solve this problem without much hassle.

<snip>

> Thayer proposed adding flagging for packages that would indicate: a)
> that it doesn't follow packaging standards and b) that it is "rotting"
> or no longer useful. This would do a few things: clean up the repo,
> keep TU motivation up, and still allow us to get new-fangled packages
> in the community repo.
> 
> The thing I like about this is that a lot of times, something new
> comes out (say dwm) and people are all "omg I want to try it!" but
> want it to be easy. That initial popularity seems, theoretically,
> enough to move it into community. But the popularity of a lot of these
> new-fangled apps tends to wane quickly. It makes sense to have a
> package like this in community as soon as one can put it there, but we
> need checks and balances to decide if it should be removed.

i like this idea, but i have a concern.

i think better statistics are essential for a successful long-term
solution to this problem.  however, i think a technical fix will only go
so far; there are *social* problems that will limit any technical fix.

example 1: votes are unreliable because voting users are not a
representative sample.

example 2: flagging packages as anything doesn't guarantee any course of
action, in any of the repositories.  bitlbee, in [extra] is 0.2.1
versions behind the upstream release.  it has been flagged-out-of-date.
the maintainer has been contacted individually.  an updated pkgbuild has
been sent to the maintainer and posted on the forums.  but it's only
getting older in [extra].

on the one hand we have users not availing themselves of the
participation mechanisms that are available.  on the other hand there
are maintainers not responding to those users who do follow-through.

so, while the aaron/thayer amendment to the proposal (or is it a
separate proposal?) provides a couple useful new statistical measures, i
don't see that it would actually generate better statistics.  several
ideas have been floated to solve this particular problem, like download
statistics.  those all need more consideration and development, though.

it seems to me that there won't be any real consensus on a concrete
proposal to regulate [community] until there's a mechanism for
generating accurate, reliable usages statistics.  i would anticipate a
close vote; given the furor that's surrounded this proposal, i would
also anticipate a lot of bad feeling on both sides arising from a close,
binding vote.

if i were a tu, i'd move to table this proposal and form a working group
to study the social and technical problems of generating good usage
statistics.  it would put off a resolution to the resource consumption
problems, but i feel that, sometimes, "now" is not better than "better."

in the meantime, it seems that moving all the games out of [community]
and into [games] is one concrete and non-controversial way to take some
load off the server.

sorry to go on at length, especially as i'm not even a tu.

yrs,
kludge