openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: How to handle the downloads?
Date Mon, 01 Aug 2011 22:38:37 GMT
Am 08/02/2011 12:03 AM, schrieb Shane Curcuru:
>
> On 8/1/2011 5:51 PM, Marcus (OOo) wrote:
>> Am 08/01/2011 09:25 PM, schrieb Ross Gardler:
>>> On 1 August 2011 18:20, Marcus (OOo)<marcus.mail@wtnet.de> wrote:
>>>> AFAIK the current projects at Apache doesn't have high download numbers
>>>> compared with OOo. So, a download request can point directly to a
>>>> mirror or
>>>> a mirror list is shown and the users have to choose themselves from
>>>> where to
>>>> get the software best.
>>>
>>> I wouldn't make any assumptions about the current mirror
>>> infrastructure. What you write above does not reflect how things work
>>> here. The ASF is a pretty large collection of projects with some very
>>> large numbers behind it.
>>
>> I've looked at this both pages:
>>
>> http://www.apache.org/dyn/closer.cgi
>> http://httpd.apache.org/download.cgi
>>
>> When comparing it with the one from the current OOo project you should
>> be able to see big differences:
>>
>> - too many links
>> - too much data on one page
>> - too much information to read to get an overview
>> - too less clear structure
>
> There are two, mostly orthogonal issues to discuss here - which is why
> it's doubly important to better document what 1) features we think OOo
> needs on it's download pages, and 2) what software & capacity is being
> used currently for OOo downloads on the Oracle infra.
>
> - Basic presentation of the download page. In most Apache projects, this
> can be controlled by the project. Thus we could better control the
> display of the physical download.cgi page itself within the Apache OOo
> project, to better explain to users what they want.

That's good.

> - Implementation of mirror choosing on the download page. This is for
> someone from infra to discuss.

But the project should have the control over it. I don't want to bother 
the infra staff for every change that has to be done. ;-)

> Separately is how mirrors are managed and rsync'd, but I'm sure once we
> figure out the above parts there can be a plan for migrating (or
> adopting) the syncing to the mirrors.

Sure, when the technical questions are answered, source and destination 
for rsync are set, too.

Marcus



>> Please keep in mind that we have to deal with end-users. Maybe there are
>> a lot of power-users but even they prefer a simple and straight
>> solution. ;-)
>>
>> Marcus
>>
>>
>>
>>> Does anyone here have the precise requirements and implementation
>>> details of the existing mirror network? It would be really useful to
>>> document that and take it to the infra team who can then evaluate what
>>> changes, if any, need to be made to the existing system.

Mime
View raw message