Callisto Coordinated Update Sites

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

Plugin Versioning Proposal

viewcvs/index.cgi/platform-core-home/documents/update.html?rev=1.3 Update Site Proposal