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

[bardo]

On Wed, Dec 3, 2008 at 12:39 AM, Allan McRae <allan at archlinux.org> wrote:
> This starts the official discussion period for the addition of rules
> governing the addition of packages to [community].  As this is essentially a
> bylaw change, we will use that voting procedure: 5 days discussion, 7 days
> voting, quorum of 75% required.

Since this is an official discussion period, I'll state my opinions in
a (hopefully!) brief form. I've been thinking about the whole thing
for quite a while now, evaluating all opposing opinions, and I have
made up my mind. Any reply is welcome.

I *won't* let the discussion end up in a flame, so don't expect an
answer to provocative e-mails. I have seen, on both sides of the
fence, a lot of people falling in the quicksands of 'a priori'
arguments. I'm trying to address the problem and the solutions I can
think of from a rational point of view.

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?
. Even if we restrict package uploading in some way, this won't mean
we'll have solved the resource problem: it will only be postponed. If
we reduce package intake by 10% (aka: more than it was proposed) it
will only take ~11% more time to hog the server resources again,
supposing all packages have the same weight. It was demonstrated that
the least used packages are pretty small, though. Not a real solution,
imho.
. With this vote we don't consider that we are *not* totally
independent from Arch, even though we theorically are. As Aaron
rightly stated, we also need to consider their opinion about the
matter. A TU-only vote does exactly the opposite, until an official
proposal comes from them.

These are the reasons why I intend to REJECT the proposal.

My (hopefully constructive) alternative proposals:
. Ask someone who knows well what s/he's taking about (a statistician)
if s/he can come up with a way to get better numbers from the means we
have, with the constraints we have, then decide how to act.
. Work with widely used third-party applications (aurvote, yaourt) to
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.

«Freedom is not the capacity to do whatever we please; freedom is the
capacity to make intelligent choices.»  -Frances Moore Lappé


Corrado Primier