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
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.)
On Jan 18, 2008 7:21 PM, w9ya@qrparci.net wrote:
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.)
1+
Very well put Bob...that is how I feel about it as well. It adds unnecessary complications for no gain. The quality versus quantity is hitting the nail head on. Actually, there has been more discussion lately of devs using community to put packages that don't necessarily fit into core/extra, so I think that practice is coming back. Thanks for writing my thoughts more eloquently than I could myself :-)
Aaron "ElasticDog" Schaefer --
aur-general@lists.archlinux.org