Hello,
We have mirrors. Almost 100 of them. Feel free to contact them all,
have them write code to count downloads which then sends the stats to
us, and then we can implement this.
What you suggest is absolutely not feasible at all.
That's too bad, I wanted to suggest counting of downloads too (because I
believe that the number downloads of particular version of a package
would after a while correlate quite well with the number of users that
actually use, i. e. upgrade this package - it should more or less solve
the problem of people trying the package and removing it quickly after
that that was mentioned).
Anyway I've been meaning to contribute with some ideas for the topic for
at least four days (since I read the first IRC log on Sunday),
unfortunately my job hasn't allowed it this week. I just wanted to do
some thinking out loud about both methods (voting/pkgstats) for both
packages already in community and those that might get there in the
future from a regular user's point of view (also with regards to
privacy/paranoia matters).
(1) pkgstats
The obvious problem with accuracy is that not everybody will use it (or
use it even from time to time to update their "contribution" to the
statistics). Some people don't know about it, some people won't be
bothered, some might be concerned about privacy. Even though IP address
is not necessarily an identifier of a person, it still a "good enough
information". I actually more or less trust Arch devs that really only a
hash of the IP is stored together with the package list but I hardly can
be sure and there are much more paranoid users out there than myself.
(Their problem doesn't have to be only with privacy itself - when
someone knows the packages you use and even the exact versions, it makes
it so much easier to target some kind of attack on the system.)
On the other hand it can be nicely used to promote a package that is in
unsupported. "Do you use this package? Do you want to see it in
community? Have you run pkgstats on you system then?" It would be nice
to see the statistics in AUR frontend, one could see how far the package
is from the magic number that makes the package a good candidate for
community (whatever the number will be).
As for pruning of community as it is now (if it still is an issue, I'm
not quite sure anymore). How about this. Pick a reasonable percentage
(it doesn't have to be the same number as the one for new packages
entering community, it can be lower) by whatever criteria (number of
packages to prune, number of MB to save, ...), create a list of all the
packages with usage below this number and create lists of these packages
grouped by their maintainers. Then send the individual maintainer-lists
to the maintainers with a note that they should consider whether or not
these particular packages are really a good material for community. At
the same time put the list of all those packages on the web, announce
its existence in the latest news and tell people that if they see a
package/packages they use and haven't yet run pkgstats, they should
probably do it now, otherwise the package might be removed from
community. Then wait for some time and look at the change in statistics
(maybe there will be some, maybe there won't).
(2) votes
Again, not everybody uses it. Especially since voting means that you
have to have an AUR account. Today everybody has tons of accounts at
different internet services, ideally one should have as many passwords
as possible, and people don't like to create yet another account (I know
I don't). Frankly, if I hadn't needed those about 15 packages I now
maintain in unsupported (because I hadn't found them there), I wouldn't
have created an AUR account either.
There's another problem with accuracy. Even users who have an account
and vote don't vote for every single package they use. Especially many
people (myself included) probably never voted for packages already in
community. This makes the system usable for dealing with the transition
unsupported -> community but not for the other way round. That, too,
could be helped by similar approach as above - count packages with the
least votes, create their list (lists) and urge people to vote for
packages on this list if they use them a want to see them still in
community in the future.
The problem is that this way the privacy concerns will be even bigger.
Right now if someone looked up which packages I voted for, it wouldn't
give them much of an idea which packages I actually use (because I only
voted for packages in unsupported and only for those that I had a reason
to believe that my vote might help push them to community). After
applying the above suggestion, anyone who gained access to AUR data
knows more or less about all community packages that a certain nickname
uses (which is much worse that knowing that this list of packages is
used by someone with this hash of IP address - which is the information
pkgstats provides). Moreover, each nickname is associated with an e-mail
which is then more or less associated with a particular person. Of
course, the e-mail can be fake (or completely or almost unused), on the
other hand if you also want to maintain some packages in unsupported,
you want to have a valid e-mail, so, if you're paranoid, you'd probably
have to have two AUR accounts - one connected to you for maintaining
packages and the other one as "anonymous" as possible just for voting.
Conclusion
Unfortunately, I don't have a solution. Both systems can be made more
accurate (and useful for pointing fingers at packages that really aren't
all that much used) but at the price of some amount of privacy or even
security. I still think that the best solution would be counting
downloads, because it would be quite accurate and also quite anonymous
(definitely more than pkgstats or voting) but sadly it's not an option.
I hope I haven't wasted too much time of those who have read it all. If
so, then I apologize :-), but I felt that when I spent some the time
thinking about these matters on my way to work and back this week, I
should share the thoughts.
Ondřej
--
Cheers,
Ondřej Kučera
