[aur-general] Policy for [community] packages

[w9ya at qrparci.net]

> As suggested by Aaron I want to discuss whether we need a policy to
> decide what packages go into [community].
> Should this decision be based on the number of votes a package has?
> Should we discuss each [community] candidate on the mailing list as it's
> done with [extra] candidates?
> Or should each TU decide on his own which package he wants to add to
> [community] as it's done now?
>
>
> Alex

Hey Alex and the gang;

When the AUR voting was first implemented this very thing was discussed.
Since the TU's had always decided for themselves what should go into the
repos it was a concern to the TUs that this remain the way things worked.
The voting was merely a way to help a TU make decisions. It was promised
that the voting would never be used to dictate to a TU what was placed
into the repo.

Further, the AUR's voting mechanism is NOT based on anything that can be
trusted to indicate either actual usage OR need of the downstream user.
Even a download counter may not necessarily indicate this qualitative
quantity.

A TU remained a TU because he or she was doing a *Quality* job, and it was
also promised that *quantity* (either too much or too little) was NEVER to
be used as a criteria for continued participation as a TU. Adding any
particular package to the repo was specifically the job of a DEV and NOT
the job of a TU. It was promised that this distinction would always be the
case.

Why? Well the TU repo was designed to be more loosely run than the repos
the dev's used. It was to be a place for new ideas and packages that were
of a personal nature to a TU. Anyone could become a TU as long as they
showed enough talent and concern about Quality. The ONLY obligation of a
TU was to maintain a TRUST by QUALITY. At one point even the dev's were
encouraged to use the TU repo for binaries that they felt did not belong
in the dev. maintained repo. Although this practice has fell by the
wayside, it still has merit.

Specifically Arch was always a distro that encouraged participation and
new ideas. It also emphasized a K.I.S.S. principle and the values that
most linux distros share in terms of being both volunteer based and a
meritocracy. <- I personally can think of no better way to insure that we
stray from these ideals than to make up too many rules and too many
obstacles to anyone desiring to participate as they can and are
able to do. i.e. We should all find ways to make the TU position one of
something other than a JOB that requires too much other than personal
fulfillment.

And remember that ANY time to make things more specific and rigid, you
WILL have unintended consequences and worse a real chance for blow-back
affecting you personally. It certainly will make the TU position less
attractive to request and THEN we ALL suffer.


Very best regards;

Bob Finch

Liviu Librescu - În veci pomenirea lui.
(May his memory be eternal.)