incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: mirrors, release publishing...again
Date Mon, 23 Apr 2012 20:39:23 GMT
On Thu, Apr 19, 2012 at 9:57 PM, Mark Ramm <> wrote:
>> A few ways, some worse than others:
>> 1) Offer several download links:  "Download from Apache, from
>> SourceForge, from MirrorBrain". Of course that doesn't balance the
>> load, but maybe it would if we randomized the order that they are
>> listed.
>> 2) Have a single link, but it is JavaScript that then directs to one
>> of the three mirrors systems.  This is easy to distribute the load
>> according to a defined schedule.  Marcus prototyped an approach like
>> this. It looked like it was working.  I'm not sure, however, whether
>> it handled fallbacks.  For example, you randomly select to use the
>> Apache mirror, but the particular operator chosen is down.  User
>> experience for backing out of that and repeating was as nice as it
>> could be.
>> 3) Some variation on 3 where we handle the fallbacks better, or at
>> least handle failures better, so the user just needs to click again.
> I would be in favor of a forth option suggested by Andreas in another thread:
> * Route "autoupdater" traffic through one system (MirrorBrain)
> * Route web based traffic through another (SF as primary, and Apache
> mirrors as secondary)
> This eliminates potential problems with "which mirror network is
> having a problem" kinds of debugging which would be particularly
> pernicious if we randomized anything about the process. It also has
> the benefit of most closely matching Joe's original suggestion of how
> to use, and provides a clear accountability/support chain for
> users when downloads fail.
> will as previously mentioned provide an API to collect stats on
> downloads from our system, and we'd be happy to help host a bouncer
> that forwards requests to a MirrorBrain server so that updater stats
> can be collected as well if that helps the team measure the release
> download volume more effectively.

Hi Mark,

I like your idea.  +1.

First, it is simple and easy to implement.  Second, we're in the
middle of our 3.4 Release Candidate vote and we don't have time to
implement, debug and tune something more complicated right now.

We could be less than a week from release at this point.  We've been
discussing AOO mirror for longer than that now.  We've also been
running, successfully, with 3.3.0 downloads going through SourceForge
for longer than that.  So I think it is time to stop designing the
next generation system (and I'm guilty as anyone for this) and move
forward with the stable download support we're going to need very soon
for AOO 3.4.


> --Mark Ramm
> ====
> This e- mail message is intended only for the named recipient(s) above. It may contain
confidential and privileged information. If you are not the intended recipient you are hereby
notified that any dissemination, distribution or copying of this e-mail and any attachment(s)
is strictly prohibited. If you have received this e-mail in error, please immediately notify
the sender by replying to this e-mail and delete the message and any attachment(s) from your
system. Thank you.

View raw message