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 "Callisto Coordinated Update Sites"
m (Coordinated Update Sites moved to Callisto Coordinated Update Sites) |
m (minor fixes on the way to next version) |
||
| Line 1: | Line 1: | ||
| + | == Purpose of this document == | ||
| − | + | 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 [http://www.eclipse.org/projects/callisto.php Callisto simultaneious release] but some of the information would be helpful 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 become a 'plan', and then, eventually, grow into a true "process and procedures" document. | |
| + | This document 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. The agreement was that I ([[User:David williams|David williams]]) would coordinate the effort ... but the projects still had to do the work! | ||
| − | + | This document is in no way to "take over" any of the Eclipse base project [http://www.eclipse.org/platform/index.html 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. Of course, bugs and feature requests may result, and that is fine, but I wanted to be clear this proposal is not for anything fundamentally new ... it is just to document what's already possible, and make sure it is coordinated and carried out with "best practices". | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
== Use cases == | == Use cases == | ||
| Line 17: | Line 15: | ||
There are 3 primary use cases that cross-project, coordinated update sites provide: | There are 3 primary use cases that cross-project, coordinated update sites provide: | ||
| − | 1. Allow end-users to install some minimum "platform" and | + | 1. Allow end-users to install some minimum "platform" and from that be able to use Update Manager to install all of the Callisto release, just by going to just one update site and selecting just one thing. |
| − | 2. Allow committers and developers to install an | + | 2. Allow committers and developers to install an "SDK" version of Callisto, to be used while developing their own plugins. |
| − | 3. Allow adopters to provide their own update sites, and "point to" appropriate sites to pick up prerequisite features. | + | 3. Allow adopters to provide their own update sites, and "point to" appropriate sites to pick up prerequisite features. While there is nothing in this Callisto effort to support this directly, Callisto should serve as a good example of "best practices" for other projects to follow. |
| + | == Objectives and Constraints == | ||
| + | Besides promoting the use cases given above, there are other objectives and constraints 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 should make it easy to "get started" with "all" of Callisto. But, in the Eclipse spirit of allowing projects to "do their own thing" they should also have their own discovery (and update) sites as well. This allows the central "getting started" site to be one-size fits all, but still allow projects to offer special features such as tools, examples, etc., that may not be part of their "main' deliverables. | |
| − | + | 3. Some sites (corporations) can establish an "corporate" update site, which may have its own policies about what updates when, etc. The process and proceures here should do nothing to interfere with that capability. | |
| − | + | == Fundamentals == | |
| − | + | === Distributed Storage === | |
| − | + | Each project will still have its own disk space and area on Eclipse, and will still be responsible for providing jarred features and plugins there, as they would for their own update site. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | === | |
"map" to pre-req's URL (with pseudo random mirror code). | "map" to pre-req's URL (with pseudo random mirror code). | ||
| Line 57: | Line 53: | ||
minimal | minimal | ||
| − | ok to "hide" required features and just "pre-req" them with "requires". | + | ok to "hide" required features and just "pre-req" them with "requires" and archive tags. |
== Planned Tests and trial runs == | == Planned Tests and trial runs == | ||
Revision as of 20:59, 2 February 2006
Contents
Purpose of this document
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 simultaneious release but some of the information would be helpful 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 become a 'plan', and then, eventually, grow into a true "process and procedures" document.
This document 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. The agreement was that I (David williams) would coordinate the effort ... but the projects still had to do the work!
This document 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. Of course, bugs and feature requests may result, and that is fine, but I wanted to be clear this proposal is not for anything fundamentally new ... it is just to document what's already possible, and make sure it is coordinated and carried out with "best practices".
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 from that be able to use Update Manager to install all of the Callisto release, just by going to just one update site and selecting just one thing.
2. Allow committers and developers to install an "SDK" version of Callisto, to be used while developing their own plugins.
3. Allow adopters to provide their own update sites, and "point to" appropriate sites to pick up prerequisite features. While there is nothing in this Callisto effort to support this directly, Callisto should serve as a good example of "best practices" for other projects to follow.
Objectives and Constraints
Besides promoting the use cases given above, there are other objectives and constraints 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 should make it easy to "get started" with "all" of Callisto. But, in the Eclipse spirit of allowing projects to "do their own thing" they should also have their own discovery (and update) sites as well. This allows the central "getting started" site to be one-size fits all, but still allow projects to offer special features such as tools, examples, etc., that may not be part of their "main' deliverables.
3. Some sites (corporations) can establish an "corporate" update site, which may have its own policies about what updates when, etc. The process and proceures here should do nothing to interfere with that capability.
Fundamentals
Distributed Storage
Each project will still have its own disk space and area on Eclipse, and will still be responsible for providing jarred features and plugins there, as they would for their own update site.
=
"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" and archive tags.
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.