| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| <title>Archive Servers</title> |
| </head> |
| |
| <body> |
| |
| <h2>Archive Servers</h2> |
| |
| <h3>Introduction</h3> |
| |
| <p>OpenOffice.org is a fairly large project, available for many combinations of languages and platforms. Thus, we currently offer a broad range of files on |
| our mirroring network that are quite large in size. Some of them are requested quite often, whereas some of them are old, legacy and only downloaded once in |
| a while. Therefore, we need to establish a policy on how to mirror the files in an economical way.</p> |
| |
| <h3>Current situation</h3> |
| |
| <p>Currently, we distribute all of them in two mirror modules: the "main" module and the "extended" module, whereas the "main" module is divided into several |
| categories. The "main" module is mirrored by many mirrors, whereas the "extended" module - due to its size - is being mirrored only by a few ones. This |
| hierarchy should not be changed. However, in order to shrink the size of all modules, we want to establish a new module called "archive", where we can store |
| the mentioned old, legacy and rarely downloaded files and move them out of "main" or "extended" modules. The "archive" module is only mirrored on two or |
| three mirrors to avoid too much traffic consumption. <b>We currently <u>DO NOT</u> need new mirrors mirroring the archive set.</b></p> |
| |
| <h3>Location of the archive set</h3> |
| |
| <p>The archive set is available at:</p> |
| |
| <ul> |
| <li><a href="http://archive.services.openoffice.org/pub/openoffice-archive/">http://archive.services.openoffice.org/pub/openoffice-archive/</a></li> |
| <li><a href="ftp://archive.services.openoffice.org/pub/openoffice-archive/">ftp://archive.services.openoffice.org/pub/openoffice-archive/</a></li> |
| </ul> |
| |
| <h3>Detailed structure of the modules</h3> |
| |
| <p>Roughly spoken, the modules should be functioning as follows:</p> |
| |
| <p>The "main" set should only contain the last released version for each platform and language, including source code. For a transition time after each |
| release, "main" should contain two builds until all download webpages have been adjusted.</p> |
| |
| <p>The "extended" set should contain things like Beta Releases and Release Candidates (.../extended/<version number>) and developer builds |
| (.../extended/developer/<milestone>) |
| before they get final, as these files are requested quite often. "extended" is also the right choice for L10N, SDK, ISOs and additional dictionaries. Files |
| that are only requested rarely should be put into "archive".</p> |
| |
| <p>The "archive" module should contai old versions. However, as storing each and any version is quite senseless, and explodes disk space rapidly, only the |
| last version of each code tree for the combination platform and language should be stored. Examples: 1.0.3.1, 1.1.5, eventually 2.4.1; but also things like |
| 1.1.2 for LinuxPPC, which is the last version for this platform. Apart from its name, "archive" is also dedicated to builds that would normally fit into |
| "extended" but are rarely downloaded.</p> |
| |
| <p>And, last but not least: Experimental stuff, very old builds etc. should not be in the mirror at all. No one needs an unsupported OpenOffice.org version |
| for a dead architecture on an unknown platform mirrored anywhere.</p> |
| |
| </body> |
| </html> |
