Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Talk:Callisto Coordinated Update Sites"
(commented on the comments (not sure how to best do that with wike)) |
|||
| Line 28: | Line 28: | ||
[dmw: yep, this is the question to be answered empiracally and via community feedback ... but if we get one packaging working ... a few others should be easy --- though, I'd never want to get to the point of a Callisto user having more than, say, 4 or 5 choices ... those users that want more fine grained control than that will have to use project update URLs] | [dmw: yep, this is the question to be answered empiracally and via community feedback ... but if we get one packaging working ... a few others should be easy --- though, I'd never want to get to the point of a Callisto user having more than, say, 4 or 5 choices ... those users that want more fine grained control than that will have to use project update URLs] | ||
| + | |||
| + | [nickb] I agree that making people download EVERYTHING is both overkill and will overtax the infrastructure. However, as David points out, "enabling" projects like EMF and GEF are required for the more newb-friendly projects, so could we have a set of screenshots just showing people how to use UM and the various requirements they need to check off in order to get the projects they want? I like what WTP has done for their [http://download.eclipse.org/webtools/updates/ UM site], for example. | ||
| + | |||
| + | By the way, I'm working on a tool to track download stats for EMF (and later, other projects who want to implement it), which combines | ||
| + | |||
| + | * a PHP script which runs SQL queries at the eclipse.org download stats database, | ||
| + | * a set of 3 cronjobs (actually, one shell script w/ three different options) for nightly/weekly/monthly querying using that interface, and | ||
| + | * a [http://emf.torolab.ibm.com/emf/downloads/downloads.php web UI] to display those results for trending and overall results (eg., combining monthly data across a year or weekly data across a quarter; or comparing 4 consecutive weeks to see if downloads increase or decrease over time) | ||
| + | |||
| + | The purpose for us is: | ||
| + | |||
| + | * to track how many hits we get in a day/week/month (survey says: [http://emf.torolab.ibm.com/emf/downloads/downloads.php?type=File&groups%5B%5D=groupSmall&groups%5B%5D=groupType&range=ym&rangeLimit=-1 over 2 million EMF jar downloads and 80,000 zip downloads in Dec & Jan]) | ||
| + | * to track how those hits change overtime | ||
| + | * to determine which files are more popular than others (ie., should the Callisto UM site include XSD? survey says: [http://emf.torolab.ibm.com/emf/downloads/downloads.php?type=File&groups%5B%5D=groupSmall&thresh=1000&groups%5B%5D=groupProject&groups%5B%5D=groupType&range=ym "*xsd*"&&!"*emf*" to "*emf*" =~ 20:1 (zips)], which means EMF-only and EMF SDK (incl. XSD) zip downloads are 20x more downloaded than XSD-only zips) | ||
| + | * to compare UM installs vs. zip downloads, to see which is more prominently used (survey says: [http://emf.torolab.ibm.com/emf/downloads/downloads.php?type=File&groups%5B%5D=groupSmall&groups%5B%5D=groupType&range=ym&rangeLimit=-1 jars to zips =~ 19:1]) | ||
| + | |||
| + | If you feel these tools/stats would be of value to other projects, I'd be happy to volunteer the code (and time to help set it up) for any other Callisto projects you'd like to track. See /cvsroot/org.eclipse/www/emf/downloads/ | ||
Revision as of 00:01, 5 February 2006
My comments (Kim Moir platform-releng) :-)
(1)There is a problem with the url http://update.eclipse.org/updates/callisto/
Currently, the platform team stores all its updates in this directory
http://update.eclipse.org/updates
and subdirectories such as these
http://update.eclipse.org/updates/3.0 http://update.eclipse.org/updates/3.1
So I don't know that this is the best url for Callisto
http://update.eclipse.org/updates/callisto/
given that we already have platform content in that directory we can't change the Apache alias for platform because this has been hardcoded in our feature.xmls the unix permissions on the directory mean that the platform team would need to retain ownership in order to continue update the content in the existing update sites.
[dmw: agreed, we should have 'callisto' first in the URL, and keep it "parallel" other Eclipse projects]
(2)Providing Callisto as a single download comprising all 10 projects provides better exposure to the newer projects. By the same token, it also forces people to download stuff that they may not necessarily want or ever use, thus significantly increasing the strain on the distribution infrastructure. It is also rather overwhelming for a new eclipse user. My point is, perhaps there is a better way to educate users and provide choice while simultaneously exposing the full breadth of functionality available with Callisto.
[dmw: yep, this is the question to be answered empiracally and via community feedback ... but if we get one packaging working ... a few others should be easy --- though, I'd never want to get to the point of a Callisto user having more than, say, 4 or 5 choices ... those users that want more fine grained control than that will have to use project update URLs]
[nickb] I agree that making people download EVERYTHING is both overkill and will overtax the infrastructure. However, as David points out, "enabling" projects like EMF and GEF are required for the more newb-friendly projects, so could we have a set of screenshots just showing people how to use UM and the various requirements they need to check off in order to get the projects they want? I like what WTP has done for their UM site, for example.
By the way, I'm working on a tool to track download stats for EMF (and later, other projects who want to implement it), which combines
- a PHP script which runs SQL queries at the eclipse.org download stats database,
- a set of 3 cronjobs (actually, one shell script w/ three different options) for nightly/weekly/monthly querying using that interface, and
- a web UI to display those results for trending and overall results (eg., combining monthly data across a year or weekly data across a quarter; or comparing 4 consecutive weeks to see if downloads increase or decrease over time)
The purpose for us is:
- to track how many hits we get in a day/week/month (survey says: over 2 million EMF jar downloads and 80,000 zip downloads in Dec & Jan)
- to track how those hits change overtime
- to determine which files are more popular than others (ie., should the Callisto UM site include XSD? survey says: "*xsd*"&&!"*emf*" to "*emf*" =~ 20:1 (zips), which means EMF-only and EMF SDK (incl. XSD) zip downloads are 20x more downloaded than XSD-only zips)
- to compare UM installs vs. zip downloads, to see which is more prominently used (survey says: jars to zips =~ 19:1)
If you feel these tools/stats would be of value to other projects, I'd be happy to volunteer the code (and time to help set it up) for any other Callisto projects you'd like to track. See /cvsroot/org.eclipse/www/emf/downloads/