Difference between revisions of "Callisto Coordinated Update Sites"

Revision as of 19:19, 2 February 2006

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.

This page was started because 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 (David williams) agreed to document how to do it. See (need participants page here).

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 their responsibilities. 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 ... it is just to document what's already possible, and make sure it's coordinate and carried out with the "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" and/or get "all" of Callisto. But, in the Eclipse spirit of allowing project to "do their own thing" they should also have their own update and discover sites as well.

3. Some corporations can establish an "corporate" update site, which may have its own policies about what updates when, etc. The objective here is to do nothing to interfere with that capability.

Fundamentals

Distributed Storage

"map" to pre-req's URL (with pseudo random mirror code). Will need a small table of "if request received that looks like this", then "map it to a URL that looks like that".

Cental site and web page to get started. This site will have one (maybe two or three) agregate features that includes all the projects.

Each project must have its own update site, discovery site, and web page.

Web and User Interface Consistency

Function, user readable formats versions in features only

minimal ok to "hide" required features and just "pre-req" them with "requires".

Planned Tests and trial runs

Near end of January, initial ones just to download "all of Callisto" to see how it does. (from several parts of the world).

Near EclipseCon (mid March), we will have a complete M5 "stack" available for use.

Related

Basics of Update Sites

Plugin Versioning Proposal

Update Site Proposal