unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 50686@debbugs.gnu.org, stefan@marxist.se, larsi@gnus.org
Subject: bug#50686: Show number of downloads on packages on GNU ELPA/NonGNU ELPA
Date: Mon, 11 Mar 2024 15:07:04 -0500	[thread overview]
Message-ID: <db79abac-66f1-409c-8cf7-9991481aea6f@alphapapa.net> (raw)
In-Reply-To: <jwvedcjwkqb.fsf-monnier+emacs@gnu.org>

Hi Stefan,

On 3/9/24 08:37, Stefan Monnier wrote:
>>> If you go to http://elpa.gnu.org/packages/ you'll now see a new column
>>> "Rank" which shows a percentile ranking for each package.
>> That's very cool.  I guess it's not looking very far back in the download
>> data (yet?),
> 
> 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?

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

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

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

Which could be updated when the logs are processed (omitting any logged 
download from before the LAST_UPDATED timestamp).  And while that 
wouldn't show when the downloads occurred, it would still be useful to 
get an idea of how many users a package has (i.e. ones that actually 
install updates to it), and it would be a very small amount of data to 
store.

--Adam





  reply	other threads:[~2024-03-11 20:07 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-19 21:13 bug#50686: Show number of downloads on packages on GNU ELPA/NonGNU ELPA Stefan Kangas
2021-09-20  4:35 ` Eli Zaretskii
2021-09-20  5:54   ` Stefan Kangas
2021-09-20  6:22 ` Lars Ingebrigtsen
2023-09-07 22:05   ` Stefan Kangas
2023-09-08  8:30     ` Adam Porter
2024-03-05 23:58       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-06  0:22         ` Adam Porter
2024-03-06  2:57           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-06  5:04             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-08 23:20               ` Adam Porter
2024-03-09 14:37                 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-11 20:07                   ` Adam Porter [this message]
2024-03-11 20:28                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-03-11 20:55                       ` Adam Porter
2024-03-11 22:13                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-01 19:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-10-02 13:39   ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=db79abac-66f1-409c-8cf7-9991481aea6f@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=50686@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).