Hi,
What is the REAL reason that you want to have the localizations on
../extended ?
What kind of problems are given if you stuck to the old structure?
Basically space requirements. We would like to provide many more
languages as full installation sets instead of language-packs only, but
we have only limited space on the normal mirrors.
When you want to change our distro system, did you look at the
mirrorbrain.org (i don't know what did happen there after the post, that
the distor-system should not be changed before 3.0)?
We have taken a look at mirrorbrain.org. The problem is that the change
could not be done in time for the 3.0 release.
correction: /the change//s/a change/
Using MirrorBrain as the only distribution solution is not what we/I
want. From my POV it is very welcome to use it as an additional solution.
If the official I'm against it because:
- Less than the half of the mirros hosting the extended set!! (
http://distribution.openoffice.org/mirrors/ )
- Extended content is not that widespread than the main content.
- Description of ../extended: Un-QA'd localized binaries and other
related files ( http://distribution.openoffice.org/files.html )
I personally don't see a logic in the system to have the en-US binaries
separated. And there other things I think not the best.
P2P Torrent:
-- Torrent Provider:
--- Is the creating of the torrents garantet?
-- Torrent Seeder:
--- Is the content on the seeder servers mirrored?
--- Will the symlink on the rsync for the torrents be ok?
--- The most seeders use a flat directory structures (all files (or
symlinks) in ./ where the torrents are stored)
Valid points. So I think it makes more sense to stick to the existing
rule of providing official releases in the main area, including all
localizations, and provide RCs on ../extended. In contrast to previous
releases we would just place more full installation sets on ../extended
instead of only language-packs, which previously was the case for many
languages.
The only potential problem I see is that we might get more QA approvals
for the RC (and thus official releases to provide in the main area) than
we have space for on the normal mirrors. But I think we can handle this
by then providing these (late) languages on the extended mirrors only.
This would be the only change to the currently existing guidelines, but
I don't see another solution because space constraints would force us at
some point to resort to the space on ../extended.
Am I making sense?
Your opinion and Florian's opinion make sense.
I will stay to provide localizations via main (regular) mirrors as long
as there's enough disk space available. If not I have to use ../extended
for the rest of the files.
Kind regards, Joost
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
