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 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 



Back to the top