Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <36419E12-FAFC-4B6B-A956-BB307F611292@comcast.net>
References: <4F99DCEA.80608@gmail.com>
	<4F9B0213.5020304@apache.org>
	<CAP-ksojowyDeo4KnHW4m+-4=7q+kPYwkCgCw3F2psYd2e8f6UQ@mail.gmail.com>
	<36419E12-FAFC-4B6B-A956-BB307F611292@comcast.net>
Date: Fri, 27 Apr 2012 17:14:55 -0400
Message-ID: 
 <CAP-ksojXD2rSxb_NxjoAcu-nZJwbbizu5QBRhPKpCE=WTtL3ig@mail.gmail.com>
Subject: Re: [RELEASE] new DL test...needs review and comments,
 and probably correction
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 27, 2012 at 5:01 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Apr 27, 2012, at 1:46 PM, Rob Weir wrote:
>
>> On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescetti <pescetti@apache.org> w=
rote:
>>> Kay Schenk wrote:
>>>>
>>>> Please take a look at and give feedback on a test page for the new
>>>> /download/index.html page at:
>>>> http://www.openoffice.org/download/test/index_new_dl.html
>>>> Yes, it's a bit strange with lots of nonsense at the top that I wanted
>>>> you to see, but will of course go away in production.
>>>
>>>
>>> The page is nice, but it's the concept that leaves me dubious.
>>>
>>> We have another thread
>>> http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219
>>> where there seems to be consensus towards a solution that:
>>> 1) Uses SF (and possibly Apache) for the web-based downloads
>>> 2) Does not phase out MirrorBrain, and uses it for the updates (i.e.,
>>> downloads initiated by OpenOffice with the "Look for updates" function)
>>>
>>
>> That's what I understand as well.
>>
>>> The "possibly Apache" in 1) is due to the fact that I haven't understoo=
d yet
>>> what technology Apache will be using and if Apache will distribute only
>>> sources or binaries too (it's obvious that we as a project will release
>>> sources and binaries, but I'm not 100% sure that Apache wants to put
>>> binaries on its mirrors too: I think so).
>>>
>>> Fact is, we should avoid the random selection as much as possible, main=
ly to
>>> be able to quickly identify problems, and you will see details in that
>>> thread. The cleaner separation we can get, the better.
>>>
>>
>> So how about something very simple:
>>
>> 1) AOO 3.4 downloads use SourceForge by default from the
>> /download/index.html page. =C2=A0Just like they are doing today.
>>
>> But we also have a links there that point to Apache mirrors for:
>>
>> a) Hashes and detached signatures
>
> Hashes and detached signatures are hosted elsewhere in Apache releases. N=
ot on the mirrors.
> http://poi.apache.org/download.html
> http://tomcat.apache.org/download-60.cgi
> http://httpd.apache.org/download.cgi
>
> Joe has suggested that we follow a cgi approach for Apache mirrors. Kay a=
sked for help with this approach. I hope to have time next Monday/Tuesday t=
o dialog with Infra on this.
>
>> b) source distribution
>> c) a link to the full release tree
>>
>> In other words, no rolling the dice, noting fancy. =C2=A0100% of normal
>> users will download from SF.
>
> What Kay has done can be adapted in any direction. Let's learn how to do =
the Apache CGI approach and then make a decision by Tuesday?
>

Do we really want to beta test new Apache CGI code?   Or do we want to
go with what we've been testing live since April 11th, namely SF.

> If we allow more than one mirroring system then the user should be able t=
o choose for themselves...
>

Users want a download that works.  They have no reason to chose from
equally opaque alternatives.

> BUt we already have Marcus, Rob, Kay, Peter, Infra and SF cooking in this=
 kitchen. We can't keep redefining the problem.
>

I'd say stick with SourceForge as we originally agreed to.  Remember,
they need to balance their books on the traffic.  They did the
analysis, and incurred initial costs.  This was based on assumptions
of traffic that they would be handling.  Don't assume that giving them
less traffic saves them money.  It might actually do the opposite,
especially if they have contracted for the bandwidth and now find they
are serving up far few ads because our "cooks" have decided to play
with MirrorBrain or whatever.

We should be a good partner here and stick to what we agreed with.
Otherwise, if we start being flaky, we're less likely to see such help
in the future.

-Rob


> Regards,
> Dave
>
>>
>> 2) When we enable the automated updates, in a week or two, then we
>> decide what we want to do. =C2=A0Maybe we do it via SF. =C2=A0Maybe Mirr=
orBrain.
>> Maybe a mix,
>>
>>> On the other side, release time is approaching and I can only hope that
>>> talks between Peter Poeml (MirrorBrain author) and Apache Infra, that h=
ad
>>> started on this list, are progressing now.
>>>
>>
>> I think it is too late for any of those talks to influence how we deal
>> with AOO 3.4 initial downloads. =C2=A0But maybe the update downloads in =
a
>> couple of weeks.
>>
>> -Rob
>>
>>> Regards,
>>> =C2=A0Andrea.
>