Am 04/01/2013 03:39 PM, schrieb Rob Weir:
On Mon, Apr 1, 2013 at 9:12 AM, Marcus (OOo)<marcus.m...@wtnet.de> wrote:
Am 04/01/2013 01:49 PM, schrieb Rob Weir:
On Apr 1, 2013, at 3:54 AM, "Marcus (OOo)"<marcus.m...@wtnet.de> wrote:
Am 04/01/2013 03:20 AM, schrieb Rob Weir:
On Sun, Mar 31, 2013 at 12:07 PM, Marcus (OOo)<marcus.m...@wtnet.de>
wrote:
Many months ago we agreed to create a new file structure for the
mirrors to
get rid of some historical grown limitations and complexity.
I want to continue this and come to a final result.
Current situation:
- Mostly it's about to differenciate the files between "stable" for
en-US
files only and "localized" for all other languages.
- Due to Apache policy the source files must not be distributed by
mirrors,
but have to be offered from Apache servers only.
Is that actually true? I thought it was fine to distribute our source
tarballs via the Apache mirror network. The things that must be
distributed from the Apache dist server are the hash files and
detached signature files.
You are right, I've checked this with the current downloads. So, it can
stay as it is now.
New naming structure:
- A new structure could look like the following:
<path_on_the_mirror>/<release_**version>/<file_type>/<**
language_code>/<install_file>
Some examples to make it more realistic:
http://sourceforge.net/**projects/openofficeorg.mirror/<http://sourceforge.net/projects/openofficeorg.mirror/>
4.0.0/binaries/en-US/Apache_**OpenOffice_4.0.0_Win_x86_**
install_en-US.exe
http://sourceforge.net/**projects/openofficeorg.mirror/<http://sourceforge.net/projects/openofficeorg.mirror/>
4.0.0/binaries/it/Apache_**OpenOffice_4.0.0_Win_x86_**langpack_it.exe
http://sourceforge.net/**projects/openofficeorg.mirror/<http://sourceforge.net/projects/openofficeorg.mirror/>
4.0.0/binaries/SDK/Apache_**OpenOffice-SDK_4.0.0_Win_x86_**
install_en-US.exe
This does not match your pattern. There is no<language-code>
component to the path?
It is, have a look for the "en-US" "it", and "SDK" pattern.
Maybe a typo in you example? I see "SDK" (and "binaries") but no
language. Surely pretending that "SDK" is a language would only
complicate the logic.
As the SDK is distributed as "en-US" files we can put them also into this
dir. However, don't worry about the logic. ;-)
But I do care, since my statistics gathering tools rely on a consistent
directory structure.
Better, IMHO, to have<file-type> be more meaningful, e.g.,
"full-install", "lang-pack", "SDK", "source", etc. Pretending that the
SDK is merely another form of en-US binary is suboptimal.
Sure, "SDK" could be also a file-type instead of a language.
Marcus
http://www.apache.org/dyn/aoo-**closer.cgi/ooo/<http://www.apache.org/dyn/aoo-closer.cgi/ooo/>
4.0.0/source/aoo-4.0.0-src.**tar.bz2
What do you think?
This is fine. Could even do without the<file_type> directory. If
you do then directly to the<language_code> directory, everything is
clear by the file name.
Sure, but someone (or more people) wanted to have another sub-dir. But I
don't remember who it was.
Otherwise we end up with many directories
with only a very small number of files in them.
I don't think so. When you look at the following I wouldn't call it a
small number of files:
http://sourceforge.net/**projects/openofficeorg.mirror/**
files/localized/ar/3.4.1/<http://sourceforge.net/projects/openofficeorg.mirror/files/localized/ar/3.4.1/>
However, I don't care. Of course we could elleminate "<file_type>" from
the pattern when we could come to an agreeement.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
