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

Aaron Griffin aaronmgriffin at gmail.com
Fri Dec 5 11:26:59 EST 2008

On Fri, Dec 5, 2008 at 8:56 AM, bardo <ilbardo at gmail.com> wrote:
> 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.

This is something that was brought up by Thayer in a personal email to
me, and I just wanted to throw this out there. This is my summary of
_his_ thoughts, and not my opinion exactly.

What we're trying to address here is not packages getting _into_
community, but package _rot_ (ed: I *love* the term "package rot").
That is, it's not the volume of packages going into community that's
the issue, it's the fact that none of them leave. A package that was
popular a month ago may not be popular today.
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.

Again, this is not my idea, and I'm not saying "omg let's do this
instead". I'm just throwing it out there to try to get real discussion

More information about the aur-general mailing list