Notice: This Wiki is now read only and edits are no longer 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 21: | Line 21: | ||
we can't change the Apache alias for platform because this has been hardcoded in our feature.xmls | 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. | 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. | (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] |
Revision as of 17:25, 4 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]