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.
Callisto Coordinated Update Sites
Contents
Temporary disclaimer
I'm learning how to use "wiki", and if you come across this page via wiki recent change logs, web searches, etc., then be warned its still very preliminary ... if I learn to use wiki well enough, I'll have it reviewed and eventually "linked" or distributed (and will then remove this temporary disclaimer).
Purpose of this page
This page is to document processes and procedures for providing improved coordination of update sites provided by the many Eclipse Projects. It's focus is on the 10 or so projects as part of the Callisto release (mid-year 2006) but some of the information would be relevent to any Eclipse Project.
Note: as of this initial writing, this should be taken as a proposal, and as reviewed and discussed and improved by others, will eventually grow into a true "process and procedures" document.
I (--David williams 02:29, 23 January 2006 (EST)) have started this page as part of a cross-project agreement reached at the December, 2005 EMO Architecture Council Meeting. There, through their representatives to the Architecture Council, the projects of the Callisto releaes agreed to improve the cross-project update experience, if I agreed to document how to do it.
Use cases
There are 3 primary use cases that cross-project, coordinated update sites provide:
1. Allow end-users to install some minimum "platform" and then be able to use Update Manager to install all or parts of the Callisto release, by going to just one update site.
2. Allow committers and developers to install an appropriate "SDK" to use while developing their own plugins.
3. Allow adopters to provide their own update sites, and "point to" appropriate sites to pick up prerequisite features.
Objectives
This page is in no way to "take over" any of the Eclipse base project update team's function, proposals, or responsibilities.
It is also not to add to them. The goal for Callisto release is to use and "push the limits" of the current capabilities and technologies of the Update Manager (bugs and feature requests may result, and are fine, I'm just documenting that this proposal is for nothing fundamentally new ... just to coordinate what's already possible, and recommend "best practices").
Besides promoting the use cases give above, there are other objectives to meet:
1. The distrubtion of Eclipse projects must fit in to its current "mirror system" to allow for distributed bandwidth.
2. There should be something of a "central site" (that takes little work to maintain) that could be used to "get started". But, in the spirit of allowing project to "do their own thing" they should be able to have their own update sites as well.
Fundamentals
Distributed Storage
"map" to pre-req's URL (with pseudo random mirror code).
cental site and web page to get started
each project must have its own update site and web page
Web and User Interface Consistency
Function, user readable formats versions in features only
Tests to guage bandwidth
These will start near end of January, initial ones just to download "all of Callisto" to see how it does.
References
viewcvs/index.cgi/platform-core-home/documents/update.html?rev=1.3 Update Site Proposal