Sigh....

I do NOT normally comment here and certainly NOT with the tone I am about to use. But you guys (plural) are attempting to dictate binding discussions without first doing your own due diligence. Or you are asking me and others to do your due diligence for you? This is, of course, very troubling to me. It should be to other TUs too.

It is NOT a given that the voting statistics are accurate or even "..somewhat accurate". MANY reasons have been given in the past why such accuracy is not possible under the current voting scheme, so I again ask you to do your due diligence, i.e. PLEASE, PLEASE, PLEASE do a search on previous discussions about this that have taken place (repeatedly) over (at least) the last couple of years.

This insistence to NOT do this searching on previous discussions before issuing your **opinions**, and declaring them as having some form of accuracy (facts) is troubling !!

I know for a *FACT* that many of my packages are used, some VERY heavily and by MANY users and yet have NO votes. I will give you here but two of the several reasons;

1 - I maintain an offshoot version of archlinux, derived from faunos, called "shackstick". It is used and is becoming quite popular amongst the ham radio community. It is packaged as a whole and the user does NOT download packages or even is part of the arch linux community, so NO votes are taken. Yet it uses over 25 of my packages that would seem to otherwise be without votes.

2 - Since the votes are NOT reflective of downloads, and for the above reason downloads are NOT reflective of the numbers of users, and FURTHER many users do NOT vote, there can be NO correlation between votes and usage. It isn't even a rough estimate.

Best regards;

Bob Finch

P.S... If the problem is that the server's output needs to be improved, then that should be the focus of the discussion from the very beginning LONG BEFORE we discuss ANY specific options (voting restrictions). If that was why this topic came up again, thank you for at least announcing it now instead of after we spent more time on this voting=server space. (And server space needs not, and should not be affecting it becoming "bogged down" as that usually is a throughput issue.

On Mon, Nov 10, 2008 at 7:59 AM, Loui Chang <louipc.ist@gmail.com> wrote:
On Mon, Nov 10, 2008 at 07:20:22AM -0700, w9ya wrote:
> I would like to remind everyone that the TU system was NOT originated solely
> to be based on votes, in fact there was no voting until much more recently.
>
> Also, when the voting was added to the TU system the community and TUs were
> SPECIFICALLY told that the voting system would NEVER be used to make
> decisions about or demands concerning what any individual TU decided to add.
> There WERE concerns that just this type of "accounting" would be used to
> determine how or what a TU may do. ONLY the TUs themselves make these
> decisions. It has ALWAYS been that way.
>
> BTW.... I am not sure why this happens every few months or so, but it is a
> repeating thought that somehow the voting system is a milestone setter and
> thereby an issue for the TUs. If there is something in the wiki or other
> documentation that would suggest or even say as much IT NEEDS TO BE REMOVED.
>
> Guys, if this is not clear to you, a search of the older mails should yield
> a wealth of information about this from previous outbursts concerning the
> suggested requirments for TUs from the voting system results.

This thread diverged from: [arch-dev-public] pkgstats: first results

If you have packages in community with zero or one votes there is a
problem. You are abusing the resources of community plain and simple.

Your packages should definitely have one vote (yourself).
If you can't even garner one other person to vote there's not much point
in putting the package into community. You'll upload it to the server,
it will cost diskspace and bandwidth as it propagates through the
mirrors, and no one will use it.

Of course votes are not an absolute indicator of usage, but they are
somewhat accurate as pkgstats shows.

This means we need to change the way community is managed so we can make
more efficient use of our resources.

I've created a wiki page to outline my ideas:
http://wiki.archlinux.org/index.php/Community

Another point to consider is that gerolde (the Arch Linux server)
is already being taxed to the point where it is becoming unstable.
We can either try to do something to help the situation, or
we can protect some maintainer's pride of having 100 unused packages in
community.