On Fri, Apr 6, 2012 at 12:11 PM, Marcus (OOo) <marcus.m...@wtnet.de> wrote:
> Am 04/06/2012 04:34 PM, schrieb Rob Weir:
>
>> Please note:  https://issues.apache.org/ooo/show_bug.cgi?id=119194
>>
>> I'm about to apply this patch. It will cause download requests to go
>> to the SourceForge mirrors instead of MirrorBrain.  We want to confirm
>> that things are set up properly on the SF side, before we get the
>> deluge of downloads for AOO 3.4.
>>
>> So please respond to this post with any oddities you see or hear about
>> with users downloading OOo 3.3 releases over the next few days.
>
>
> Please tell me that you have tested the patch and are sure it's working
> without problems. ;-)
>

Yes, that is why we have staging and production servers.

> Otherwise I'm pretty sure something was not changed and it will lead to a
> broken download service.
>
> In any way, I recommend to setup a test phase in the test area
> (http://www.openoffice.org/download/test/). Here we can do some try & error
> games until it's working, without any interference of the production area.
>
> OK, back to the patch:
>
> "sf_download_main.patch":
> This shouldn't be necessary as the host for the download link should also
> come from a varialbe and not from hard-coded links.
>
> It seems this wasn't changed until now. I'll do this, then the patch is not
> needed.
>
> "sf_download_isos.patch":
> The distribution of the ISO files wasn't integrated into the download
> service; except that the files were hosted by a server with MirrorBrain.
>
> BTW:
> Have we already discussed about these ISO files? Do we want to continue
> this? If not, IMHO no need to migrate a dead service.
>
> "sf_download_main.patch":
> This is the heart of the download logic. Up to now only MirrorBrain was
> used. In former times also Bouncer (from OSUOSL) but there were many changes
> to make the migration from Bouncer to MirrorBrain successful. So, I don't
> know yet if the changes in the patch are complete to offer another
> alternative or if there is something more to change.
>

I would not treat the patches as the final UI or final logic that we
will use for 3.4.  It is just a way to test the SF mirror under some
load.  We can revert these patches once the test is over, or move to
something else.

For example, we might have logic that sends 75% of the traffic to SF
mirrors and 25% to Apache mirrors.  We could adjust that with a
parameter in the script and tune it based on capacity.

-Rob

> Marcus
>

Reply via email to