unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Adam Porter <adam@alphapapa.net>
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 16:28:25 -0400	[thread overview]
Message-ID: <jwvfrwwmsov.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <db79abac-66f1-409c-8cf7-9991481aea6f@alphapapa.net> (Adam Porter's message of "Mon, 11 Mar 2024 15:07:04 -0500")

>> 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	other threads:[~2024-03-11 20:28 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
2024-03-11 20:28                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
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=jwvfrwwmsov.fsf-monnier+emacs@gnu.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=50686@debbugs.gnu.org \
    --cc=adam@alphapapa.net \
    --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).