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