Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Download stats was: Building from git?

Hi Team,

Results:

Results
Query took 0.074 sec (0.003 connect time)
File (click for daily stats) Count
/stats/org.eclipse.ocl.feature 1
/stats/org.eclipse.ocl.all.sdk.feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl_3.1.0.v201106-1427_feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.examples_3.1.0.v20110606-1427_feature 1
/stats/org.eclipse.ocl.examples.feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.all_3.1.0.v20110606-1427_feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.all.sdk_3.1.0.v20110606-1427_feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.core.sdk_3.1.0.v20110606-1427_feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl_3.1.0.v20110606-1427_bundle 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.uml_3.1.0.v20110606-1427_feature 1
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.master_3.1.0.v20110606-1427_feature 1


11 records found. 11

This looks fine to me. So if I don't receive any objection, our final Indigo release repository is ready.

For Indigo, we will have an idea if our releases repository is really used.
For Indigo SR1, when adding download stats to indigo repository, we will have an idea about how much Eclipse OCL is being downloaded.

Best Regards,
Adolfo.

El 16/06/2011 11:38, Adolfo Sánchez-Barbudo Herrera escribió:
Hi Team,

Today, the stats downloads are as expected, the new org.eclipse.ocl.examples feature was registered.:

Results
Query took 0.076 sec (0.003 connect time)
File (click for daily stats) Count
/stats/org.eclipse.ocl.feature 1
/stats/org.eclipse.ocl.all.sdk.feature 1
/stats/org.eclipse.ocl.examples.feature 1


3 records found. 3

 I've finally done the following:

- I've set the following p2.statsURI attribute for the Inidigo release repository: http://download.eclipse.org/stats/modeling/mdt/ocl/updates/releases/3.1.0
- I've used the following pattern for the download.stats attribute: artifact-Id_artifact-version_artifact-type.

I've also decided to register stats for the OCL Ecore and UML features, so that if I downloaded the OCL All-in-one SDK from our P2 repository, I would expect the following download stats:

/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl_3.1.0.v201106061427_bundle
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl_3.1.0.v201106061427_feature
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.uml_3.1.0.v201106061427_feature
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.all_3.1.0.v201106061427_feature
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.core.sdk_3.1.0.v201106061427_feature
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.all.sdk_3.1.0.v201106061427_feature
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.examples_3.1.0.v201106061427_feature
/stats/modeling/mdt/ocl/updates/releases/3.1.0/org.eclipse.ocl.master_3.1.0.v201106061427_feature

I'm going to test that, tomorrow the results.

Cheers,
Adolfo.
El 15/06/2011 16:20, Adolfo Sánchez-Barbudo Herrera escribió:
Hi all,

Well, I think that it's interesting having some kind of download stats rather than not having anyone.

From your comments, I conclude that registering plugin downloads is not a useful record...since we don't really know if the plugin was download because of a dependency of a third party project or a by a real OCL user... Again I think that it's better having an extra information, rather than not having it.... We can't say that OCL has 'n' users, but we can say that OCL has been downloaded 'm'times, which it's much better than saying nothing.

On the other hand, considering features downloads rather than plugins. We could think that if our OCL End User SDK feature was downloaded, we could say that it was probably downloaded by a real OCL user (via install new software). This is not true and let's see a couple of use cases:

- I want to download OCL Editors and I obviously select in the installation wizard our OCL Examples feature. However, since I have the idea that OCL editors are based on Xtext, I (unnecessarily) select the Xtext SDK as well. Xtext SDK would have an extra download, from a non real Xtest user.
- In spite of the fact that features usually set feature dependencies/requirements at a plugin-level (using the "compute" button, or to avoid the download of unnecessary plugins) a feature may also set a dependency (requirement) on a feature instead of a plugin. Supposing that Papyrus and/or Acceleo features depended on the OCL 'all in one' SDK feature, instead of the plugins they really need, we would have the same problem: a non real OCL user, would be downloading (and registering) our OCL SDK.

So my conclusions about this topic are the following:

- We can't expect from these stats mechanisms an estimation of real OCL users, but as a simple artifacts (features and plugins) downloads count (which in my opinion is good)
- In principle, to register an artifact download stat, the finer grain could be the feature. However it looks like that registering our core plugin (org.eclipse.ocl) could give us an idea of how much widespread Eclipse OCL is really being used (regardless it's used by real OCL users, or by third party projects dependencies).
- Tracking all features (instead of just OCL End User SDK and OCL Examples) could be helpful to have an idea if our features organization is being exploited by clients).

For these reasons, I would register download stats for the following features/plugins:
- Plugins:
     - org.eclipse.ocl
- Features:
     - org.eclipse.ocl.all (OCL Runtime)
     - org.eclipse.ocl.core.sdk (OCL Core SDK)
     - org.eclipse.ocl.all.sdk (OCL End User SDK)
     - org.eclipse.ocl.examples (OCL Examples and Editors).
     - org.eclipse.ocl.master (OCL All In One SDK)

Best Regards,
Adolfo.
El 15/06/2011 13:41, Willink, Ed escribió:
Hi Axel

There was a recent cross-project-issues-dev message, from Wayne Beaton
suggesting
discontinuing the UDC since its statistics were dubious and unable to used
for
privacy resons.

	Regards

		Ed 

-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx 
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Axel Uhl
Sent: 15 June 2011 13:20
To: MDT OCL mailing list
Subject: Re: [mdt-ocl.dev] Download stats was: Building from git?

Is there maybe a way to hook up to the anonymous statistics gathering 
that users can opt in for when installing Eclipse? I've never been 
looking at it from a committer's angle, but I would expect 
there to be 
some way we could collect information about who is really 
starting the 
bundles. Perhaps there are even APIs we could use in our 
implementations 
to collect more fine-grained information?

Best,
-- Axel

On 6/15/2011 2:14 PM, Willink, Ed wrote:
Hi Adolfo

I saw these threads and realised that stats was one of many 
things that we
could catch up on.

I think relative is equally intreresting to absolute, so 
even if mirrors are
lost hopefully it's in proportion.


How many users of Ecore wrt UML
How many users of Pivot wrt Ecore
How many users of IA wrt Ecore
How many users of Editors wrt Ecore
...

How many direct Ecore users compared to indirect Acceleo users

..

I'm not sure how many of these can be answered given the 
amount of parasitic
bundle downloading that goes on.

Just because UML is downloaded doesn't mean it's used.

I suspect that we will get an inclusive number that fails 
to distinguish
satisfied users from disappointed experimenters,
and for which the relative values are of limited meaning. 
(My personal OCL
downloads might be 50 per year!).

Hence, I didn't push to get these working.

	Regards

		Ed

-----Original Message-----
From: mdt-ocl.dev-bounces@xxxxxxxxxxx
[mailto:mdt-ocl.dev-bounces@xxxxxxxxxxx] On Behalf Of Adolfo
Sánchez-Barbudo Herrera
Sent: 15 June 2011 13:07
To: mdt-ocl.dev@xxxxxxxxxxx
Subject: Re: [mdt-ocl.dev] Download stats was: Building from git?

Bad news,

I've been reading a long thread in cross project 
concerning download
stats...

Quiting David Williams:

"Any *'download.stats'*properties from your artifact
repository should
be copied over to the common one. "

So, since our milestones builds (RCs) didn't have said
"download.stats"
properties, the downloads done from the indigo repository [1]
will never
be registered.

Downloads from our Indigo release repository [2] will be
registered, but
I'm afraid that most of potential downloads will probably
come from the
main Indigo one... Perhaps, the only advantage will be having
some kind
of information to know if somebody is using our releases 
repository...
On the other hand, I have more interesting comments:

- Quoting Martin Oberhuber:
"1. It is better to tie stats to a FEATURE rarther than a bundle.
Because bundles come
      in 2 variants (.pack.gz / .jar) so with a bundle you
have duplicate
work adding the
      stats tracker (and, the app from bug 310132 which 
auto-generates
stats properties
      doesn't support it).
1a) Note though that a commercial product which uses a
different feature
      structure than Eclipse Open Source (and so just gets
your bundle) won't
      be counted when you count feature access. That's likely
not relevant."

When automating, 1 should not be relevant. However 1a) 
comes with an
interesting question. Are we really interested in knowing if other
components downloads an ocl plugin (for instance Acceleo, 
or whoever
depends on Eclipse OCL) ?:
     - Yes: We should probably track download stats from
org.eclipse.ocl
plugin (the core plugin, which will always exist if somebody wants
Eclipse OCL).
     - No: Just tracking features should suffice.

[1] http://download.eclipse.org/releases/indigo
[2]
http://download.eclipse.org/modeling/mdt/ocl/updates/releases/3.1.0

Best Regards,
Adolfo.

El 15/06/2011 11:16, Adolfo Sánchez-Barbudo Herrera escribió:
Hello All,

El 14/06/2011 16:44, Adolfo Sánchez-Barbudo Herrera escribió:
Likewise, there should be some stats recording from our release
repository. I'll need to check some test results, which will be
tracked by the download stats tools tomorrow. The tool to
check the
stats may be accessed through the portal (thanks Laurent
for pointing
this tool out):
Here we have the results. The test was installing the OCL
End User SDK
in a clean Indigo RC4 Eclipse Classic installation:

*Results*

Query took 0.065 sec (0.007 connect time)
File (click for daily stats) 	Count
/stats/org.eclipse.ocl.feature 	1
/stats/org.eclipse.ocl.all.sdk.feature 	1

	
2 records found. 	2


The features which are currently tracked are the following:
- org.eclipse.ocl
- org.eclipse.ocl.all.sdk
- org.eclipse.oxl.examples

The conclusion is: Installing the OCL End User SDK
(org.eclipse.ocl.all.sdk feature) also make the included
features be
registered (in this case, the org.eclipse.ocl one).

So I think that it could be interesting making all the features be
tracked instead of simply using the ocl.all.sdk.feature one. The
reasons are:
- We could track if any other thirdparty P2 repository tried to
download a narrow feature from our release repository 
(i.e OCL Core
SDK, OCL Runtime, etc.. )
- We could have an idea if the feature organization is
being useful.
If OCL End User SDK has the same hints as OCL Core SDK,
means that the
latter is not being used/useful for our clients).

Apart from making all our features be registered I want to
do a couple
of things more:
1. Now I want to install the OCL Examples in a clean installation.
Examples doesn't include other features, but depend
on/requires some
plugins (also ocl plugins). I would like to know what
happens in this
case. I suppose that the depending plugins will be simply
downloaded
from the repository, and no hints for the other features will be
registered (I think that this is the same situation for downstream
projects such as Acceleo). We could also register hints 
for plugins
(perhaps the narrower one: org.eclipse.ocl), although I
read somewhere
that it's better to register hints from our features (I'll
try to look
for more information about this).

2. Add some version information of the feature so that different
repositories (even nightly/milestones) have different 
stats for the
same feature. I was thinking about trailing the feature
version behind
the feature name. However, this would make harder to track
the content
registered for the repository in the portal web UI. So
instead of having:
/stats/org.eclipse.ocl.feature-3.1.0.vAAAABBCC-ddee
/stats/org.eclipse.ocl.feature-3.1.0.vFFFFFGGHH-iijj
...
/stats/org.eclipse.ocl.all.sdk.feature-3.1.0.vAAAABBCC-ddee
/stats/org.eclipse.ocl.all.sdk.feature-3.1.0.vFFFFFGGHH-iijj

I was think about trailing the version in the beginning:

/stats/3.1.0.vAAAABBCC-ddee-org.eclipse.ocl.feature.
/stats/3.1.0vAAAABBCC-ddeej-org.eclipse.ocl.all.sdk.feature.
...
/stats/3.1.0.vFFFFFGGHH-iijj-org.eclipse.ocl.feature.
/stats/3.1.0.vFFFFFGGHH-iijj-org.eclipse.ocl.all.sdk.feature.

Another interesting alternative: Including our project name
and build
information:

/stats/mdt-ocl-3.1.0.RAAAABBCCDDEE-org.eclipse.ocl.feature.

/stats/mdt-ocl-3.1.0.RAAAABBCCDDEE-org.eclipse.ocl.all.sdk.feature.
...
/stats/mdt-ocl-3.1.0.NFFFFFGGHHIIJJ-org.eclipse.ocl.feature.

/stats/mdt-ocl-3.1.0.NFFFFFGGHHIIJJ-org.eclipse.ocl.all.sdk.feature.
Thoughts ?

Best Regards,
Adolfo.
--
Open Canarias, S.L.
	*Adolfo Sánchez-Barbudo Herrera*
adolfosbh(at)opencanarias(dot)com
<mailto:adolfosbh%28at%29opencanarias%28dot%29com>
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
--
Open Canarias, S.L.
	*Adolfo Sánchez-Barbudo Herrera*
adolfosbh(at)opencanarias(dot)com
<mailto:adolfosbh%28at%29opencanarias%28dot%29com>
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231


Please consider the environment before printing a hard copy of this
e-mail.

The information contained in this e-mail is confidential. 
It is intended
only for the stated addressee(s) and access to it by any 
other person is
unauthorised. If you are not an addressee, you must not 
disclose, copy,
circulate or in any other way use or rely on the 
information contained in
this e-mail. Such unauthorised use may be unlawful. If you 
have received
this e-mail in error, please inform us immediately on +44 
(0)118 986 8601
and delete it and all copies from your system.

Thales Research and Technology (UK) Limited. A company registered in
England and Wales. Registered Office: 2 Dashwood Lang Road, 
The Bourne
Business Park, Addlestone, Weybridge, Surrey KT15 2NX. 
Registered Number:
774298

Thales UK Limited. A company registered in England and 
Wales. Registered
Office: 2 Dashwood Lang Road, The Bourne Business Park, Addlestone,
Weybridge, Surrey KT15 2NX. Registered Number: 868273

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev

_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

Back to the top