Difference between revisions of "Archive Mirrors"

From Apache OpenOffice Wiki
Jump to: navigation, search
(Initially copied from http://distribution.openoffice.org/mirrors/archive.html)
 
 
Line 24: Line 24:
  
 
And, last but not least: Experimental stuff, very old builds et al. shouldn't be in the mirror at all. No one needs an unsupported OpenOffice.org version for a dead architecture on an unknown platform mirrored anywhere...
 
And, last but not least: Experimental stuff, very old builds et al. shouldn't be in the mirror at all. No one needs an unsupported OpenOffice.org version for a dead architecture on an unknown platform mirrored anywhere...
 +
 +
[[Category:Website]]

Latest revision as of 13:37, 15 November 2010

Introduction

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.

Current situation

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 quite a few mirrors, whereas the 'extended' module - due to its size - is being mirrored only by a dozen one. This hierarchy shouldn't 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'. The 'archive' module is only mirrored on two or three mirrors to avoid too much traffic consumption. We currently DO NOT need new mirrors mirroring the archive set.

Location of the archive set

The archive set is available at

Detailed structure of the modules

Roughly spoken, the modules should be functioning as follows:

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 pages and Bouncer entries have been adjusted. Additionally the 'main' set includes en-US binaries of release candidates (../contrib/rc) and developer builds (../developer).

The 'extended' set should contain things like experimental Mac OS X builds or experimental builds for other platforms before they get final, as these files are requested quite often. 'extended' is also the right choice for URE, SDK, release candidates, CWSs, ISOs and additional dictionaries. Files that are only requested rarely should be put into 'archive'.

The 'archive' module should contain archived 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.

And, last but not least: Experimental stuff, very old builds et al. shouldn't be in the mirror at all. No one needs an unsupported OpenOffice.org version for a dead architecture on an unknown platform mirrored anywhere...

Personal tools