On Sun, Jan 9, 2011 at 11:41 AM, Magnus Therning <email@example.com>wrote:
> On 09/01/11 18:21, Thomas S Hatch wrote:
> > Yes magnus, arch has pkgstats which is similar to popcon, but the
> > instalation is completely volountary.
> Doing anything but a voluntary thing would be VERY difficult for many
> I think ;-)
> > it is a good resource, but something more granular would be nice.
> What do you mean by "more granular"?
> Magnus Therning OpenPGP: 0xAB4DFBA4
> email: firstname.lastname@example.org jabber: email@example.com
> twitter: magthe http://therning.org/magnus
Right, it needs to be voluntary, of course
, but the problem is that the
results of the pkgstats, while useful, are still singled out to a subset of
users. This of course breaks the reliability of the statistical analysis. So
pkgstats is a good indicator of package use, such that if a package shows up
a lot on pkgstats then we have a viable indication of popularity.
But the opposite cannot be reliably assessed, this is because the subset of
users using pkgstats does not reflect a random sampling of users, therefore,
statistically it is very feasible for there to be large unrepresented swaths
By "granular" I mean "more accurate", the problem here is of course is the
question of how this is done.
The Fedora project uses a system called smolt to track Fedora installations,
it runs during the firstboot process and returns a monthly report to Fedora
about hardware and installation information.
Fedora feels somewhat confident that smolt returns fairly accurate
information, mostly because it is turned on by default.
But even then, it can only reflect a subset, since it is still opt in and
The next argument would be to incorporate a server side solution, that just
traces how many times individual files are downloaded. The problem here is
that it requires that we ask the mirrors to all run mirror side traces, and
I highly doubt they would all go for it.
I imagine there are other solutions to the problem, but the reality is that
open source is by its nature viral, and tracking this stuff is murder. So
removing something from community and placing it in the AUR is difficult,
primarily because we cannot be sure that it is not being used. Unfortunately
this method "ask around" has a number of holes too.
I know that there are criteria for bringing a package into community, I
wonder if a set of criteria or lightweight process for package removal from
community would be a good idea.
The way distributions like debian and Fedora handle this problem is by just
packaging everything - and we don't quite have the man power and interest
(all be it Arch is getting close, we have a lot of Devs and TUs now). But
also there is a question, a strong question, about whether or not that would
be an Arch philosophy solution at all. The AUR and the easy path to package
inclusion is one of the things that make Arch great.