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

[w9ya]

On Tue, Dec 2, 2008 at 9:01 PM, Aaron Griffin <aaronmgriffin at gmail.com>wrote:

> 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!"
>

Well Aaron, even proponents of this proposal have said that the statistics
and/or votes are a problem as far as accuratcy. Heck a simple examination
shows that the voting system has over two orders of magnitude for a variable
and NO basis for determining the shape of the possible distribution of votes
, so no understanding of what then constitutes a mean either.

AND you have again said it is needed to be doing this. So for the past
several weeks many have been asking why.

Would you PLEASE explain why this is needed. In detail, and with some
statistics that can be verified and have a good basis in compilation. As it
would be NICE to know exactly WHY this is NEEDED. And how this change
accomplishes such a needed change.

Best regards;

Bob Finch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://archlinux.org/pipermail/aur-general/attachments/20081202/d4b61166/attachment.htm>