RE: [cross-project-issues-dev] Download stats and p2

[Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>]

Doing this has several issues:
1) you change the bytes on people. So I may think I have version 1.0.0, but in reality I have the "old" version of it as you updated it. Also I have to way to update to it and also you have no way to tell easily what I'm running.
2) this simply does not work because p2 dependency resolution mechanism is driven by p2 metadata and not the features.

"Wenfeng Li" ---06/12/2009 07:37:24 PM---Yes, downloading features is simple and minimal impact to performance. It also help to address the bottleneck concern. One be

From:	"Wenfeng Li" <wli@xxxxxxxxxxx>
To:	"Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
Date:	06/12/2009 07:37 PM
Subject:	RE: [cross-project-issues-dev] Download stats and p2

---

Yes, downloading features is simple and minimal impact to performance.  It also help to address the bottleneck concern.  One benefit of having centralized feature files is allowing quick fix of common error that a feature spec misses plugins that it should include.
 
Wenfeng
 
 
 
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Friday, June 12, 2009 1:18 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Download stats and p2
 
Works for me :). Simple and automatic.
On Fri, Jun 12, 2009 at 3:51 PM, Eric Gwin <eric.gwin@xxxxxxxxxx> wrote:
If it is p2 downloads then the "files" to track would simply be the features correct? or am I missing something.

-Eric


Wayne Beaton wrote:
Greetings all. We have a small problem. Actually, I guess that the problem is as big as you choose to decide it is...

The Eclipse Foundation tracks downloads that go through the download.php script:

http://www.eclipse.org/downloads/download.php?file=[...]

This includes things like the packages and direct downloads provided by projects (assuming that everybody is using the script in their download links).

Downloads that occur through p2 do not go through this script. They go directly to our download server and to our mirrors. The mirrors do not (and arguably cannot reasonably) provide us with download stats.

So... if somebody, for example, downloads the "Eclipse IDE for PHP Developers" we will know that we have one more download of PDT. If they instead download the "Eclipse IDE for Java Developers" and then use p2 to add PDT to their configuration, we currently do not have any way of tracking that download of PDT.

Inability to accurately track downloads is a huge concern for the Eclipse Board.

We have explored several mechanisms for tracking this download. Unfortunately, we've not been holding these conversations as publicly as I'd like, so I'll summarize them briefly below...

1. Get mirrors to give us their download stats. We could ask. But most will not give them to us. Besides, their logs probably contain information about everything they mirror, which will be way more information than we need. And it'll be a heck of a lot of information for our webmasters to weed through.

2. Add a plug-in that gathers information from p2 post install and send that information to eclipse.org. Effectively, this is a call-home mechanism that will require some additional UI elements and considerable effort awfully late in our development cycle. Ultimately, it will require some kind of opt-in from the user; many of whom will refuse leaving us with incomplete data. FWIW, we could use the UDC for this, but it has the same problem.

3. All p2 downloads go through eclipse.org. Denis is concerned that the download.php script and--to some degree--the rest of our infrastructure will not be able to scale to handle the value that can potentially come from p2 downloads. FWIW, we're not increasing our bandwidth for Galileo; instead, we're depending very heavily on mirrors.

Bug 239668 [1] has been open for some time to discuss this issue.

We've decided that the best approach is something that we've been calling the "Single File Hack". In this hack, we configure the p2 metadata (artifacts.xml) to send requests for some small subset of the files to eclipse.org. Ideally, we send requests for one plug-in or feature for each thing that we need to track. The number of files needs to be kept relatively small.

There are problems with this hack. For one, eclipse.org becomes a single point of failure for all downloads. Further, we will have to let organizations that mirror our downloads for internal consumption know how to turn it off.

What we're going to need from each project is the names of the files that we need to be tracking.

I'd love to hear your thoughts on this topic.

Wayne

[1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=239668
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
 _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev