[jbosstools-issues] [JBoss JIRA] (JBIDE-12432) Investigate enabling p2 download statistics

Max Rydahl Andersen (JIRA) jira-events at lists.jboss.org
Wed Apr 17 10:12:54 EDT 2013


    [ https://issues.jboss.org/browse/JBIDE-12432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767964#comment-12767964 ] 

Max Rydahl Andersen edited comment on JBIDE-12432 at 4/17/13 10:12 AM:
-----------------------------------------------------------------------

answer to @nickboldt from JBIDE-12432:

"JOB_NAME defines which update site was used to pull the resources, as it describes the update site (jbt aggregate, jbt tests, jbt webtools, jbtis, etc.)"

I can see value in knowing which updatesite it is from -  but the jobname are just insanely long and duplicate alot of info in the url (i'm thinking about how to make it easy to extract and summarize data from this). We can keep it for knowing which site it is from but would be great if it could just actually be the site and not alot of other info.

"project.groupname = org.jboss.tools regardless of the site being built, so that's not as helpful."

Not following you here - this means there is a stable and unique field to look for.

"As to the order of the path segments, you agreed to this in November. Why is it NOW a problem, 5 months later?"

Because back then we just put in what we got to evaluate later ? 

"Besides, it's arbitrary. The whole point is to collect data which can be parsed later. Having more segments allows you to filter the http log on different pieces of metadata. Fewer segments == fewer filter options."

This is exactly why ordering and what data is collected is good. Makes the filtering *easier* if it is consistent.

"Perhaps you want to see ALL the hits for Alpha2? Filter on BUILD_ALIAS
Or you want all the hits for a given feature, regardless of which milestone in which it was released. Filter on feature ID."
 
"Or if you want all the hits for the whole release, filter on project.version == 4.1.0-SNAPSHOT.
I would rather capture more than we need in case we need it later, rather than have to revisit this in 5 months when someone realizes we failed to collect something useful, and we've lost 5 months of data."

Yes I agree on that, but the sequence of elements has to be the same otherwise that data cannot be collected/compared.

Anyways, looking through the data and your descriptions above I agree the various elements each have their place/value, but having the project.version first now that we don't have a JBT_VERSION just still seems wrong to me.

How about:


{{http://download.jboss.org/jbosstools/usage/installs/${JOB_NAME\}/${project.version\}/${BUILD_ALIAS\}/${buildQualifier\}/}}

Then the project.version is "contextual" since I assume the project.version in some cases are from an individual component and in others an aggregator.

Thus project.version is not "global" anymore, but the "job_name" is and the sequence then keeps a natural and easier to filter/browse hiearchy.


                
      was (Author: maxandersen):
    answer to @nickboldt from JBIDE-12432:

"JOB_NAME defines which update site was used to pull the resources, as it describes the update site (jbt aggregate, jbt tests, jbt webtools, jbtis, etc.)"

I can see value in knowing which updatesite it is from -  but the jobname are just insanely long and duplicate alot of info in the url (i'm thinking about how to make it easy to extract and summarize data from this). We can keep it for knowing which site it is from but would be great if it could just actually be the site and not alot of other info.

"project.groupname = org.jboss.tools regardless of the site being built, so that's not as helpful."

Not following you here - this means there is a stable and unique field to look for.

"As to the order of the path segments, you agreed to this in November. Why is it NOW a problem, 5 months later?"

Because back then we just put in what we got to evaluate later ? 

"Besides, it's arbitrary. The whole point is to collect data which can be parsed later. Having more segments allows you to filter the http log on different pieces of metadata. Fewer segments == fewer filter options."

This is exactly why ordering and what data is collected is good. Makes the filtering *easier* if it is consistent.

"Perhaps you want to see ALL the hits for Alpha2? Filter on BUILD_ALIAS
Or you want all the hits for a given feature, regardless of which milestone in which it was released. Filter on feature ID."
 
"Or if you want all the hits for the whole release, filter on project.version == 4.1.0-SNAPSHOT.
I would rather capture more than we need in case we need it later, rather than have to revisit this in 5 months when someone realizes we failed to collect something useful, and we've lost 5 months of data."

Yes I agree on that, but the sequence of elements has to be the same otherwise that data cannot be collected/compared.

Anyways, looking through the data and your descriptions above I agree the various elements each have their place/value, but having the project.version first now that we don't have a JBT_VERSION just still seems wrong to me.

How about:


{{http://download.jboss.org/jbosstools/usage/installs/$\{JOB_NAME\}/$\{project.version\}/$\{BUILD_ALIAS\}/$\{buildQualifier\}/}}

Then the project.version is "contextual" since I assume the project.version in some cases are from an individual component and in others an aggregator.

Thus project.version is not "global" anymore, but the "job_name" is and the sequence then keeps a natural and easier to filter/browse hiearchy.


                  
> Investigate enabling p2 download statistics
> -------------------------------------------
>
>                 Key: JBIDE-12432
>                 URL: https://issues.jboss.org/browse/JBIDE-12432
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: updatesite
>            Reporter: Max Rydahl Andersen
>            Assignee: Nick Boldt
>             Fix For: 4.1.0.Alpha2
>
>
> Just learned about http://wiki.eclipse.org/Equinox_p2_download_stats today.
> Sounds like OpenShift hosted collector plus some queries to a db could do alot on getting some better updatesite usage info!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


More information about the jbosstools-issues mailing list