Hi Florian, thanks for the quick reply.
Bircher Florian schrieb:
Hello, First for the RC or the official release?
The initial proposal was meant to work for official releases. But given your feedback I think we have to reconsider some aspects (see below).
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.
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? Regards, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
