Talk:Callisto Coordinated Update Sites

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]