Show PPA download stats in the web UI

Bug #688141 reported by Julian Edwards on 2010-12-09
474
This bug affects 97 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Low
Unassigned

Bug Description

Now that download stats are being collected, we can start to display them in Launchpad's web UI. There's a few things that we could do:

 1. Display the most popular PPAs by "heat" on the main PPAs index page (/ubuntu/+ppas). Mark Shuttelworth proposes a simple "heat" metric such as:
   5 flames: top 1% PPA in the past 6 months
   4 flames: top 10%
   3 flames: top 25%
   2 flames: top 50%
   1 flame: top 75%
   damp squib: less.
  (only count them for the latest version of any package in there, so you can't fudge it by rapid-fire publishing)

 2. On a PPA's overview page:
    * show its daily download totals, possibly with a nice graph.
    * show total download count for all packages ever published, again maybe with a graph

 3. On a PPA's package page, show download totals for individual packages

Changed in soyuz:
status: New → Triaged
importance: Undecided → Low
tags: added: ppa ui
Yury V. Zaytsev (zyv) wrote :

Sounds good to me. In what concerns individual packages, I think it might be worth adding a column to the package list (i.e. https://launchpad.net/~zyv/+archive/ppa ) with a total number of downloads of the files associated with the package.

In the detailed list view, I think, one can add download counts in parenthesis after the sizes of the individual files: https://launchpad.net/~zyv/+archive/ppa/+packages . I.e. mc_4.7.0.9.orig.tar.gz (3.8 MiB, 123 downloads)

Alin Andrei (nilarimogard) wrote :

The daily builds PPAs will always be the most used because there are... well, daily updates and thus downloads :) So this won't useful.

Alin Andrei (nilarimogard) wrote :

Oh wait, I see that the plan is to only count the downloads for the latest version. Than it should be OK so please ignore my above comment.

Fabien Tassin (fta) wrote :

otoh, if it's for the latest version only, it won't be of much use for daily builds, for which the version doesn't really matter.

As a maintainer of a lot of daily builds, i need stats to:
1/ see which dists are popular and need continuous love vs which dists could be dropped because they no longer have (enough?) active users
2/ how many people i gain and loose over time for a particular ppa/pkg/dist/arch.

My case here may be a bit special. I want to be able to put some figures on http://people.ubuntu.com/~fta/ppa-dashboard/chromium-daily.html and http://people.ubuntu.com/~fta/ppa-dashboard/ubuntu-mozilla-daily--ppa.html

I'm especially interested to see if people migrate from a channel to another, or from the official archive to a ppa or back.
Also, how long does it take for users to upgrade after a security update lands.

Nicolas Palix (npalix) wrote :

I agree with Fabien.

As a package maintainer, releasing -rc and backports, I want to have feedback
on which dist/arch I need to put efforts on.

I also want to know if users migrate from the official package to the edge one.

However in my case, it is not daily builds but releases synchronized with upstream.
I think in that case a monthly or quarter counters will be more appropriate.

One may also want to select start and end dates to generate various graphs.

Scott Ritchie (scottritchie) wrote :

Seeing the download totals for older builds would be useful as well, that way I can get a sense of the changing popularity of the PPA from one release to the next

Something to worry about if you're ranking by "most current package download totals" is what happens immediately after a new binary release before everyone's update manager does its daily query. A formerly very popular PPA would drop to nothing temporarily. So for that reason you might want to look at the maximum of the current version and the previous 3 or so (successfully built) versions

William Grant (wgrant) wrote :

Scott, you can pass getPublishedBinaries a status argument to find the stats for older builds.

May I ask if there is any progress on this bug?

Roel Van de Paar (roel11) wrote :

33 People who request this. Maybe this can be implemented asap?

Jonathon F (jonathonf) wrote :

Up to 72 people now.

And now 83 :-)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions