incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: [RELEASE]: proposed directory structure on dist
Date Mon, 30 Apr 2012 18:31:59 GMT

On Apr 30, 2012, at 10:44 AM, Rob Weir wrote:

> On Mon, Apr 30, 2012 at 1:25 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>> 
>> On Apr 30, 2012, at 6:29 AM, Jürgen Schmidt wrote:
>> 
>>> On 4/30/12 9:12 AM, Jürgen Schmidt wrote:
>>>> On 4/27/12 10:09 PM, Kay Schenk wrote:
>>>>> 
>>>>> 
>>>>> On 04/27/2012 12:47 PM, Marcus (OOo) wrote:
>>>>>> Am 04/27/2012 09:34 PM, schrieb Dave Fisher:
>>>>>>> 
>>>>>>> On Apr 27, 2012, at 12:12 PM, Marcus (OOo) wrote:
>>>>>>> 
>>>>>>>> Am 04/27/2012 08:49 PM, schrieb J�rgen Schmidt:
>>>>>>>>> On 4/27/12 5:32 PM, Kay Schenk wrote:
>>>>>>>>>> 2012/4/27 J�rgen Schmidt<jogischmidt@googlemail.com>
>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> to be prepared for the upcoming release I plan
to use the following
>>>>>>>>>>> directory structure on
>>>>>>>>>>> 
>>>>>>>>>>> https://www.apache.org/dist/**incubator/ooo<https://www.apache.org/dist/incubator/ooo>
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Existing
>>>>>>>>>>> 3.3
>>>>>>>>>>> 3.3/patches
>>>>>>>>>>> 3.3/patches/cve-2012-0037/...
>>>>>>>>>>> DATE
>>>>>>>>>>> KEYS
>>>>>>>>>>> 
>>>>>>>>>>> New added:
>>>>>>>>>>> 3.4.0/source
>>>>>>>>>>> 3.4.0/windows/...
>>>>>>>>>>> 3.4.0/windows/languagepacks/..**.
>>>>>>>>>>> 3.4.0/macos/...
>>>>>>>>>>> 3.4.0/macos/languagepacks/...
>>>>>>>>>>> 3.4.0/linux-x86/...
>>>>>>>>>>> 3.4.0/linux-x86/languagepacks/**...
>>>>>>>>>>> 3.4.0/linux-x86-64/...
>>>>>>>>>>> 3.4.0/linux-x86-64/**languagepacks/...
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 16 languages: en-US ar cs de en-GB es fr gl hu
it ja nl ru pr-BR
>>>>>>>>>>> zh-CN
>>>>>>>>>>> zh-TW
>>>>>>>>>>> 
>>>>>>>>>>> Do we need to prepare or adapt the download page?
>>>>>>>>>>> 
>>>>>>>>>>> Juergen
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Juergen--
>>>>>>>>>> 
>>>>>>>>>> This will considerably change the current logic being
used. Is
>>>>>>>>>> there some
>>>>>>>>>> reason you don't want to use the existing setup of:
>>>>>>>>>> 
>>>>>>>>>> root DL area/files/stable/3.4/...
>>>>>>>>>> root DL area/files/localized/3.4/...
>>>>>>>>>> 
>>>>>>>>>> see:
>>>>>>>>>> 
>>>>>>>>>> http://sourceforge.net/projects/openofficeorg.mirror/files/
>>>>>>>>> 
>>>>>>>>> I had a look to other projects in the dist folder on
Apache and
>>>>>>>>> looked
>>>>>>>>> what we already have.
>>>>>>>>> 
>>>>>>>>> From my point of view the old structure doesn't really
make too much
>>>>>>>>> sense.
>>>>>>>>> 
>>>>>>>>> Why should we for example put the localized bit in separate
>>>>>>>>> directories
>>>>>>>>> when we have the language Id as part of the name?
>>>>>>>>> 
>>>>>>>>> And we have only stable releases in the future. Ok we
will have
>>>>>>>>> archives
>>>>>>>>> of older versions but that's it.
>>>>>>>>> 
>>>>>>>>> Do we have the time to adapt it to the new structure.
We should do
>>>>>>>>> it ow
>>>>>>>>> if possible.
>>>>>>>>> 
>>>>>>>>> What do others think?
>>>>>>>> 
>>>>>>>> It won't work because the DL logic is working the old way,
and only
>>>>>>>> this way. ;-)
>>>>>>>> 
>>>>>>>> The old structure has everything in a single directory. The
only
>>>>>>>> separation is for en-US only (stable) and all other languages
>>>>>>>> (localized).
>>>>>>>> 
>>>>>>>> When we change the structure now where the builds are physicaly
>>>>>>>> existing, then we have to adapt the complete logic, too,
which is an
>>>>>>>> effort that I cannot predict.
>>>>>>>> 
>>>>>>>> So, the best solution is to keep the old separation and think
about
>>>>>>>> to change this with a new release.
>>>>>>>> 
>>>>>>>> Then I would prefer to have every install file for a specific
version
>>>>>>>> in a single directory. This makes it the easiest way to assemble
>>>>>>>> download links:
>>>>>>>> 
>>>>>>>> Example:
>>>>>>>> 
>>>>>>>> <root-path>/files/3.4.0/...
>>>>>>>> <root-path>/files/3.4.1/...
>>>>>>>> <root-path>/files/3.5.0/...
>>>>>>>> ...
>>>>>>> 
>>>>>>> We can only keep the most current version in Apache dist. All
older
>>>>>>> versions go to the archive.
>>>>>> 
>>>>>> Oh yes, right, then it's only one directory.
>>>>>> 
>>>>>> Marcus
>>>>>> 
>>>>> right now -- especially with the desire to continue to serve up
>>>>> "friendly" dl logic in the new /download/3.3.0 directory, this is really
>>>>> and truly critical. Yes, it's true, given the Apache current release
>>>>> dictum, we will only have one directory setup --
>>>>> 
>>>>> /dist/incubator/ooo/files/3.4.0/stable
>>>>> /dist/incubator/ooo/files/3.4.0/localized
>>>> 
>>>> ok that means I will upload the files in this way
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.asc
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.md5
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha1
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/stable/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_en-US.dmg.sha512
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/stable/...
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.asc
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.md5
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha1
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/localized/de/Apache_OpenOffice_incubating_3.4.0_MacOS_x86_install_de.dmg.sha512
>>>> 
>>>> .../dist/incubator/ooo/files/3.4.0/localized/de/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/ar/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/cs/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/en-GB/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/es/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/fr/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/gl/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/hu/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/it/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/ja/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/nl/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/pt-BR/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/ru/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/zh-CN/...
>>>> .../dist/incubator/ooo/files/3.4.0/localized/zh-TW/...
>>>> 
>>>> 
>>> 
>>> to be complete
>>> 
>>> .../dist/incubator/ooo/files/3.4.0/source/...
>> 
>> I plan to work on an Apache Mirror version that will include source. I think that
should be on the project site and can include the binaries as well.
>> 
>> The Apache style cgi is not directly compatible with the OOo MirrorBrain style nor
the SF version.
>> 
> 
> But is it the case that the scripts/cgi's are assuming a directory
> structure?  If so, the path of least resistance will probably be a
> build script that produces upload trees in the various expected
> formats.  Maybe even generates the HTML.   In other words, this might
> be easier to solve as a build issue than a site runtime issue.   But
> I'm probably wrong.

The difference is when the mirror is selected.

In the Apache cgi approach - it is all selected in the server before the dl page is displayed.

In the SF and MirrorBrain - it is selected by SF as the DL is chosen.

But yes a single file could define the paths.

We have the following dimensions - in no particular order.

(1) Mirror. (Apache, SF, MirrorBrain)
(2) Language. (en-US , ....)
(3) OS. (Windows, MacOS, Linux, ...)
(4) Package. (Binary, Source, ...)
(5) Version.

- The new DL gives SF, user lang, user OS, Binary and version 3.4.
- The new other gives SF, any lang, any OS, Binary/Source and version 3.4

- The adapted legacy gives MirrorBrain, user lang, user OS, and a version 3.3 or earlier.
- The adapted other gives MirrorBrain, any lang, any OS, Binary and version 3.3 or earlier.

- The new project site DL should be Apache, Source, version 3.4.
- Optionally add "new other" content to the project page.

We must distribute the "Apache Official" source release using Apache Mirrors. Work has been
done here as well.

Does the above look like the most reasonable set of DL pages?

Back to the problem.

We can define functions to convert these (5) pieces of information into the correct URL. Given
the differences in the approach each mirror should have a unique path generation function
that wraps the core function.

ApacheMirrorURL
MIrrorBrainURL
SourceForgeURL

should all extend OpenOfficeURL - this generates the path and this is what follows the directory
structure.

So, I would say that we will want to generate from a file. I think we can do this with the
Apache CMS. An xml file is probably best.

My goal will be to have the "openoffice.cgi" be informed by such a file.

Regards,
Dave

> 
> -Rob
> 
>> Regards,
>> Dave
>> 
>> 
>>> 
>>> Juergen
>>> 
>>>> Note that I don't use the version in the localized folders again.
>>>> Otherwise we have to change it to
>>>> 
>>>> .../dist/incubator/ooo/files/stable/3.4.0/...
>>>> .../dist/incubator/ooo/files/localized/de/3.4.0/...
>>>> 
>>>> Juergen
>>>> 
>>>> 
>>>>> 
>>>>> Seriously, once we get past this release, we could and should discuss
>>>>> this some more, but for now...we don't really have time to re-do the
>>>>> logic for a different directory setup
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message