bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#50686: Show number of downloads on packages on GNU ELPA/NonGNU ELPA


From: Stefan Monnier
Subject: bug#50686: Show number of downloads on packages on GNU ELPA/NonGNU ELPA
Date: Mon, 11 Mar 2024 16:28:25 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

>> 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.

>>> 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.

>> 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?

> As far as database size, the download counts per version (i.e. per tarball
> filename) could be stored in a table like:
>
>   FILENAME | DOWNLOAD_COUNT | LAST_UPDATED

Maybe we could keep that in addition to the current data (not sure how
useful would be the "last_updated").

Again, tho, the question is "what for?".

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.


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]