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

Aaron Griffin aaronmgriffin at gmail.com
Tue Dec 2 23:01:46 EST 2008

On Tue, Dec 2, 2008 at 5:39 PM, 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.
> [proposal]
> * Only "popular" packages may enter the repo, as defined by 1% usage from
> pkgstats or 10 votes on the AUR.
> * Automatic exceptions to this rule are:
> - i18n packages
> - accessibility packages
> - drivers
> - dependencies of packages who satisfy the definition of popular, including
> makedeps and optdeps
> - packages that are part of a collection and are intended to be distributed
> together, provided a part of this collection satisfies the definition of
> popular
> * Any additions not covered by the above criteria must first be proposed on
> the aur-general mailing list, explaining the reason for the exemption (e.g.
> renamed package, new package). The agreement of three other TUs is required
> for the package to be accepted into [community]. Proposed additions from TUs
> with large numbers of "non-popular" packages are more likely to be rejected.
> * TUs are strongly encouraged to move packages they currently maintain from
> [community] if they have low usage. No enforcement will be made, although
> resigning TUs packages may be filtered before adoption can occur.
> [end proposal]

I throw something in here during the official discussion period,
directed at all the people saying "omg these metrics suck" (regarding
pkgstats and votes).

The fact is, it's come to all our attention that we need _some_ way to
control packages in community. These are the only metrics we have at
the moment. The above bylaw, no matter what the actual metric used, is
a decent one. Modifying the metric at a later time can and should be
done, but for now these are the only metrics we have.

Simply put: some structure here is needed. If this is all we have
right now, we should do it, rather than say "screw it, let's stick
with this freeform thing we've been doing". If we find these metrics
to be wanting, we can change it later. And seriously, how hard is it
to go onto IRC or the forums and say "I want to put Foo in community,
and need 8 more votes please!"

More information about the aur-general mailing list