Show PPA download stats in the web UI

Bug #688141 reported by Julian Edwards
This bug affects 117 people
Affects Status Importance Assigned to Milestone
Launchpad itself

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

Tags: lp-soyuz ppa ui
Changed in soyuz:
status: New → Triaged
importance: Undecided → Low
tags: added: ppa ui
Revision history for this message
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. ) 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: . I.e. mc_4.7.0.9.orig.tar.gz (3.8 MiB, 123 downloads)

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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 and

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.

Revision history for this message
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.

Revision history for this message
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

Revision history for this message
William Grant (wgrant) wrote :

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

Revision history for this message
Rafał Cieślak (rafalcieslak256) wrote :

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

Revision history for this message
Roel Van de Paar (roel11) wrote :

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

Revision history for this message
Jonathon F (jonathonf) wrote :

Up to 72 people now.

Revision history for this message
H.-Dirk Schmitt (dirk-computer42) wrote :

And now 83 :-)

Revision history for this message
Antenore Gatta (antenore) wrote :

105 ;-)

Revision history for this message
Dmitry Sidorov (jonmagon) wrote :

113 people now

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

Duplicates of this bug

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.