incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: mirrors, release publishing...again
Date Fri, 20 Apr 2012 16:34:07 GMT


On 04/20/2012 09:24 AM, Rob Weir wrote:
> On Fri, Apr 20, 2012 at 6:06 PM, Kay Schenk<kay.schenk@gmail.com>  wrote:
>> On Thu, Apr 19, 2012 at 7:36 PM, drew<drew@baseanswers.com>  wrote:
>>
>>> On Thu, 2012-04-19 at 21:57 -0400, 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.
>>>
>>
>> I'll take a look at what Marcus did. It is very easy to just do a "random"
>> link based on 3 mirror systems -- ASF, SourceForge, MirrorBrain.
>>
>>
>>>>>
>>>>> 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.
>>>>
>>>
>>
>> Yes, this is desirable -- but I think this would involve more server-side
>> intelligence or ajax programming instead of simple JS.  I'd need to look
>> into it. Maybe beyond my capabilities. :/
>>
>>
>>
>>>> I would be in favor of a forth option suggested by Andreas in another
>>> thread:
>>>>
>>>> * Route "autoupdater" traffic through one system (MirrorBrain)
>>>
>>
>> Ah yes...ye olde autoupdater. As of yet, I don't think we have nailed down
>> the "format" of the feed document for this. I could be wrong, but I haven't
>> seen anything from anyone -- maybe another separate thread on this is in
>> order. I tried several approaches to make this actually work, and nothing!
>> So, this makes sense but ????? I havent' forgotten about it, I just don't
>> know what to do about it. We need very specific details on constructing the
>> atom feed and then, of course, constructing it.
>>
>>
>>>> * Route web based traffic through another (SF as primary, and Apache
>>>> mirrors as secondary)
>>>
>>> Well, that sure looks like to most sane way to go from what I've seen
>>> described - seems the cleanest way.
>>>
>>> //drew
>>>
>>>
>> OK, in summary -- I'll take a look at what Marcus has already done -- and
>> get a prototype "simple" random selection DL script out there early on next
>> week for additional comments.
>>
>
> It looks like we need to worry about three things: legacy downloads,
> AOO 3.4 downloads and OOo 3.3 upgrades.
>
> So how about something like this:
>
> 1) Legacy downloads (OOo 3.3.0 and earlier) are distributed only via MirrorBrain
>
> 2) AOO 3,4 release goes to SourceForge and Apache for download, with
> random selection and a splitting ratio that we can tune in the script.
> The script Marcus started is a good start,

1) and 2) great plan and pretty much what I was thinking as well! Good!

>
> This allows us to gain some experience working with all three
> networks, see how they perform, get user feedback,etc, before tackling
> the upgrades.
>
> Then 3) When we are ready to turn on the automatic updates for
> 3.3.0->3.4.0, then we make a choice based on what we've learned by
> doing 1) and 2).  In other words, don't worry about the update
> downloads until later, based on which one appears to have more latent
> capacity.

OK, but right now we're still plagued with the "no connection" 
business...we could just leave things like that until light dawns on 
this I guess.

Anyway, I WILL put something together early next week -- Mon, Tues -- on 
this. I'm busy over the next few days.

>
> -Rob
>
>
>>
>>>
>>>>
>>>> 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 SF.net, and provides a clear accountability/support chain for
>>>> users when downloads fail.
>>>>
>>>> SF.net 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.
>>>>
>>>> --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.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> ----------------------------------------------------------------------------------------
>> MzK
>>
>> "Women and cats will do as they please,
>>   and men and dogs should relax and get used to the idea."
>>                                                                     --
>> Robert Heinlein

-- 
------------------------------------------------------------------------
MzK

"Women and cats will do as they please,
  and men and dogs should relax and get used to the idea."
                                     -- Robert Heinlein

Mime
View raw message