Notice: this Wiki will be going read only early in 2024 and edits will no longer be 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 (Process for Update Sites) |
|||
| Line 1: | Line 1: | ||
| − | |||
| Line 13: | Line 12: | ||
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. | 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 ([[User:David williams|David williams]]) agreed to document how to do it. See (need participants page here). | |
== Use cases == | == Use cases == | ||
| Line 24: | Line 23: | ||
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. | ||
| + | |||
== Objectives == | == Objectives == | ||
| − | This page is in no way to "take over" any of the Eclipse base project | + | This page 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 | + | 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: | Besides promoting the use cases give above, there are other objectives to meet: | ||
| Line 36: | Line 36: | ||
1. The distrubtion of Eclipse projects must fit in to its current "mirror system" to allow for distributed bandwidth. | 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 | + | 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 == | == Fundamentals == | ||
| Line 43: | Line 45: | ||
"map" to pre-req's URL (with pseudo random mirror code). | "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 | cental site and web page to get started | ||
| − | each project must have its own update site and web page | + | each project must have its own update site, discovery site, and web page |
== Web and User Interface Consistency == | == Web and User Interface Consistency == | ||
| Line 53: | Line 57: | ||
versions in features only | 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. | |
== References == | == References == | ||
| − | [http:// | + | [http://www.eclipse.org/eclipse/platform-core/documents/plugin-versioning.html Plugin Versioning Proposal] |
| − | [http:// | + | [http://www.eclipse.org/eclipse/platform-core/documents/update.html Update Site Proposal] |
Revision as of 03:59, 23 January 2006
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.
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
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.