|
From: | Adam Porter |
Subject: | bug#50686: Show number of downloads on packages on GNU ELPA/NonGNU ELPA |
Date: | Mon, 11 Mar 2024 15:55:47 -0500 |
User-agent: | Mozilla Thunderbird |
On 3/11/24 15:28, Stefan Monnier wrote:
I had the logs only for a two weeks or so (plus some old logs from many years ago, actually), indeed.I see. Are the rest of the logs still available on the ELPA server, or is that all we have for historical data?That's all we have.
Ok. Going forward, will the logs we have now be preserved, or do they get rotated away?
a list of downloads per version, etc.Currently I count the "interest" in the package, so I don't distinguish the version of the package, nor whether the access is for the tarball or the package's web page, or the package's readme.txt, or the package's badge.That seems like a very different kind of data than the number of times a package has been downloaded (i.e. by an Emacs instance). IME a small fraction of hits to a package's GitHub repo seem to result in installations; "interest" tends to be far more than "interested enough to install."Just because the "interest" tends to be far more than "interested enough to install" doesn't mean that the two aren't strongly correlated. Also my impression is that package web pages in `elpa.gnu.org` are not visited nearly as often as a Github project page. But it'd be definitely worth checking how the two measures compare. Patches welcome.
Ok, meaning that you'd accept a patch that does...what, exactly, to the database? :)
I'd like to the keep the stats database reasonably small (it's currently around 150kB, and I expect it'll take a year before it reaches 1MB), so I'd rather not segregate per version.Is there a way that I could change your mind about that? Having the actual download counts per version would be very useful.Maybe if you argue about what kind of use would make it useful?
For example, if a package at version V has N downloads after 6 months, and then the package is updated to version V+1, how many downloads that version has after 6 months would give some indication of whether the package is growing in popularity, whether initial users are still using it and upgrading it, or whether it's falling out of favor. And, over time, that might help determine whether an obsolete package should be removed from ELPA.
Also, since a package's minimum Emacs version may increase when its version increases, that could provide some useful information (not that I'm suggesting to track that in the ELPA code, but some other tool could correlate the data).
My goal was mostly to show relative popularity, so when you search for packages providing a given feature and you find 4 different options, the rank percentile can give you an idea of which one is more popular.
That's definitely a worthy goal.Another goal that's relevant to me, as a package author, is to determine whether a package of mine is still in use at all. For example, my package org-ql is intended to subsume my older package, org-rifle, but I hear now and then about people who still use org-rifle. Eventually I'd like to see that the downloads of org-rifle fall off to the point that I could declare it an archived, obsoleted package, but I don't want to do that prematurely. (Those packages are on MELPA, but the principle applies regardless.)
--Adam
[Prev in Thread] | Current Thread | [Next in Thread] |