You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Roberto Galoppini <rg...@geek.net> on 2012/03/23 15:28:50 UTC
Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Hi all,
I'm resending our proposal as per previous thread 'Sourceforge and
AOO 3.4 distribution' asking for a feedback.
As Mark Ramm wrote before we could commit to delivering the full
download volume, we wanted to produce a vetted plan, including a clear
timeline and backing technical implementation plans.
What we are proposing is an elaboration of Joe’s ‘hybrid’ approach:
- Both AOO and SF.net mirror networks would be used to provide
download capacity for the 3.4 release.
- SourceForge.net would be the “recommended default download” on the website.
- Apache Mirror network would be an alternate download option.
- Apache OpenOffice team and Infrastructure team will maintain
control of the the auto-update URL’s and possibly follow Rob’s
suggestion to stagger automatic updates.
SourceForge.net will manage the full burst capacity for web-based
downloads through our global network of OSS mirrors, global CDN
network(s) and cloud file server providers. Using these resources,
we anticipate our capacity is well above the expected delivery
requirements for the upcoming release.
In addition to basic download capacity, SourceForge will provide
detailed download statistics, which will support future product,
infrastructure and marketing plans. We will commit to make stats
available on the SourceForge.net website and provide stats delivery
APIs. We are able to capture initiated downloads, not just page
views, and will provide them split by geography and operating system.
We’re also willing to consider additional stats needs.
Proposed Timeline:
- Immediately: SourceForge sets up Apache Infra team with
credentials on an AOO mirror project in sf.net
- Firsr week: SourceForge updates contracts with CDN and other
providers to handle full AOO peak release traffic
- Second Week: AOO Infra team works with sf.net operations team to
ramp traffic to sf.net in a controlled way in order to gather
statistical data, verify assumptions, and give the Apache
infrastrucure team time to verify our capacity.
- 1-2 days post test: SF.net analyzes traffic data, assures that
our assumptions about geographic mix, and interactive vs automated
download mix, are valid and we can do this in a fiscally responsible
way.
- 1-2 days post test: AOO infrastructure team analyses traffic data,
lets sf.net team know any additonal data needs, and validates that the
system will work for them
Once everything is tested and vetted on both sides, we will need to
make a CDN bandwidth commit, and would like the AOO team to commit to
notifying us 30 days prior to shutting down the flow of traffic, so
that we can update our contracts and avoid penalties.
We believe that the combination of SF.net mirrors, and CDN based burst
capacity will provide a fast and stable download experience for AOO
users, and will allow the AOO team to publicize the release in an
agressive manner.
Roberto
====
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.
Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Posted by Joe Schaefer <jo...@yahoo.com>.
As the suggestion is basically another way
of saying what I originally wrote, I am
fine with it. To the extent that my opinion
reflects the wishes of the infra team, I don't
think anyone on the team will object.
>________________________________
> From: Ross Gardler <rg...@opendirective.com>
>To: ooo-dev@incubator.apache.org
>Sent: Wednesday, March 28, 2012 7:59 AM
>Subject: Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
>
>On 26 March 2012 17:22, Rob Weir <ro...@apache.org> wrote:
>> On Sun, Mar 25, 2012 at 9:20 AM, Mark Ramm <ma...@geek.net> wrote:
>>
>>> >> - SourceForge.net would be the “recommended default download” on the
>>> website.
>>> >
>>> > What would that look like? On what page do we make this branch? In
>>> > most of our communications we will point the public to this URL:
>>> >
>>> > http://download.openoffice.org
>>> >
>>> > (That then redirects to http://www.openoffice.org/download/)
>>> >
>>> > The download link then provided to the user is matched to their
>>> > platform and language, based on their request headers.
>>>
>>> My thoughts would be that we split based on user preference at this
>>> page, by showing two links. One for the sf.net download, and another
>>> for the apache mirror network based download.
>>>
>>>
>> This sounds good to me.
>>
>> Any feedback from Apache Infra on this proposal? Or anyone else from the
>> PPMC? (Silence is consent)
>
>I think we need an explicit OK from Joe on this one with his infra hat
>on. I'll touch base with him to make sure he has read this thread.
>
>Ross
>
>
>
Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Posted by Ross Gardler <rg...@opendirective.com>.
On 26 March 2012 17:22, Rob Weir <ro...@apache.org> wrote:
> On Sun, Mar 25, 2012 at 9:20 AM, Mark Ramm <ma...@geek.net> wrote:
>
>> >> - SourceForge.net would be the “recommended default download” on the
>> website.
>> >
>> > What would that look like? On what page do we make this branch? In
>> > most of our communications we will point the public to this URL:
>> >
>> > http://download.openoffice.org
>> >
>> > (That then redirects to http://www.openoffice.org/download/)
>> >
>> > The download link then provided to the user is matched to their
>> > platform and language, based on their request headers.
>>
>> My thoughts would be that we split based on user preference at this
>> page, by showing two links. One for the sf.net download, and another
>> for the apache mirror network based download.
>>
>>
> This sounds good to me.
>
> Any feedback from Apache Infra on this proposal? Or anyone else from the
> PPMC? (Silence is consent)
I think we need an explicit OK from Joe on this one with his infra hat
on. I'll touch base with him to make sure he has read this thread.
Ross
Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Posted by Rob Weir <ro...@apache.org>.
On Sun, Mar 25, 2012 at 9:20 AM, Mark Ramm <ma...@geek.net> wrote:
> >> - SourceForge.net would be the “recommended default download” on the
> website.
> >
> > What would that look like? On what page do we make this branch? In
> > most of our communications we will point the public to this URL:
> >
> > http://download.openoffice.org
> >
> > (That then redirects to http://www.openoffice.org/download/)
> >
> > The download link then provided to the user is matched to their
> > platform and language, based on their request headers.
>
> My thoughts would be that we split based on user preference at this
> page, by showing two links. One for the sf.net download, and another
> for the apache mirror network based download.
>
>
This sounds good to me.
Any feedback from Apache Infra on this proposal? Or anyone else from the
PPMC? (Silence is consent)
> > Some subset (and we don't know what % since we're not running Google
> > Analytics here) don't want the default and click through to the full
> > matrix of downloads available:
> >
> > http://www.openoffice.org/download/other.html
>
> We can handle that however you want. We can create a sf.net page
> matching that matrix, put sf.net links in the matrix along with normal
> mirror network links, or just leave it as is. We are open to whatever
> helps the project the most.
>
> > I'm assuming that we want to avoid duplicating effort maintaining the
> > logic for automatically matching users to the right download, as well
> > as avoid SF needing to tracking in detail a large matrix of downloads,
> > availability of new translations, etc. You just want to mirror our
> > dist/incubator/ooo directory.
>
> Sourceforge.net already had user agent string + file name heuristics
> to figure out the right platform for the user and the "best match"
> download, which should work automatically. We also allow projects to
> manually choose the "best" release for any given platform. So, I
> think a simple link to
> sourceforge.net/projects/AOO/files/download/latest (for example) would
> be enough.
>
>
Here is where it could get complex. Not all languages are released at the
same time. Some might come out when 3.4 is released initially. Others
might then follow in later weeks, as the translations are completed. Some
might not be available until 4.0. So the calculation for what download to
recommend to a user is tricky, and would need to be responsive to the
changing status of translation availability.
One idea would be for us to agree on a single, canonical statement of these
matching rules/translation matrix, encoded in Javascript or XML or JSON or
something. If we centrally manage that, then SF can periodically refresh
with the latest data, on a similar schedule to rsync'ing the actual
releases.
We can probably get started even with out this, but it might reduce the
coordination pain if we eventually move to a model like that.
> So it should be easy enough for that page to display both the sf.net
> link and one going to the Apache mirror network, and those can be
> displayed in whatever way makes the most sense for marketing the
> release and managing download traffic.
>
>
OK.
> Mirroring more files is not a problem for us at all as long as we can
> use rsync or some other automated mechanism to keep the files up to
> date as there are changes.
>
> Maintaining an alternative version/platform matrix page would take a
> little bit more work, but if it's helpful we could certianly create
> something that matches that experience on the sf.net side.
>
> > Ideally (and this is my opinion. others may have better opinions), we
> > would check the user's request header, get the language and platform
> > from that, determine the recommended download, and pass that request
> > onto either of the mirror networks, along with the IP address for
> > locating the nearest mirror. The branch between Apache and SF mirrors
> > could be done randomly, based on a tune-able parameter. if
> > rand()<0.25 doApache() else doSF() would send 25% of the download
> > requests to Apache, and the remaining 75% to SF.
>
> We can certainly do this as well. Either approach is fine, but the
> approach outlined above has the advantage of requiring almost no
> integration work on either side -- so it would be my preference.
> That said, the approach you describe here could be implemented on the
> sf.net side in a day or two, so if it's your preference we're more
> than happy to accomodate that.
>
>
I think if we do branching at the top level page, 90% or more of users will
go for that first listed link. That is human nature. So if you are are
comfortable with that load then I have no objections. We could even balance
things at the Javascript level, with reordering those links to reach some
other distribution, e..g. place SF first 75% of the time, etc., depending
on what balance works best.
> > The nice thing about this approach is it allows each mirror network to
> > do their own geographic optimization, while allowing the OpenOffice
> > project to control how users are recommended a particular version of
> > AOO. It allows us to maintain the matrix of downloads in one place.
> > And it does not introduce any new mouse clicks for the user.
>
> I agree that we should try to maintain the current number of clicks.
> I also agree that we should give the OO project control of how the
> options are presented, and I like this idea.
>
> But the downside is that people might randomly get sf.net sometimes
> and apache mirrors the next, and have an inconsistent user experience.
> And I also think users should have some control over what download
> experience they get.
>
> So, overall I think Joe's suggestion of a recommended download link
> that states that it's going to sourceforge.net, and a second
> "alternate" link that goes the the Apache mirrors would probably
> provide a better user experience.
>
> > Is it technically feasible?
>
> Absolutely. I think I speak for Roberto and the rest of the sf.net
> team when I say we are open to whatever solution works best for the
> AOO project, and are more than willing to be guided by the PPMC's
> opinion on this.
>
> --
> Mark Ramm
> Director of Engineering,
> SourceForge Developer Experience
> email: mark@geek.net
> ====
> 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.
>
>
Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Posted by Mark Ramm <ma...@geek.net>.
>> - SourceForge.net would be the “recommended default download” on the website.
>
> What would that look like? On what page do we make this branch? In
> most of our communications we will point the public to this URL:
>
> http://download.openoffice.org
>
> (That then redirects to http://www.openoffice.org/download/)
>
> The download link then provided to the user is matched to their
> platform and language, based on their request headers.
My thoughts would be that we split based on user preference at this
page, by showing two links. One for the sf.net download, and another
for the apache mirror network based download.
> Some subset (and we don't know what % since we're not running Google
> Analytics here) don't want the default and click through to the full
> matrix of downloads available:
>
> http://www.openoffice.org/download/other.html
We can handle that however you want. We can create a sf.net page
matching that matrix, put sf.net links in the matrix along with normal
mirror network links, or just leave it as is. We are open to whatever
helps the project the most.
> I'm assuming that we want to avoid duplicating effort maintaining the
> logic for automatically matching users to the right download, as well
> as avoid SF needing to tracking in detail a large matrix of downloads,
> availability of new translations, etc. You just want to mirror our
> dist/incubator/ooo directory.
Sourceforge.net already had user agent string + file name heuristics
to figure out the right platform for the user and the "best match"
download, which should work automatically. We also allow projects to
manually choose the "best" release for any given platform. So, I
think a simple link to
sourceforge.net/projects/AOO/files/download/latest (for example) would
be enough.
So it should be easy enough for that page to display both the sf.net
link and one going to the Apache mirror network, and those can be
displayed in whatever way makes the most sense for marketing the
release and managing download traffic.
Mirroring more files is not a problem for us at all as long as we can
use rsync or some other automated mechanism to keep the files up to
date as there are changes.
Maintaining an alternative version/platform matrix page would take a
little bit more work, but if it's helpful we could certianly create
something that matches that experience on the sf.net side.
> Ideally (and this is my opinion. others may have better opinions), we
> would check the user's request header, get the language and platform
> from that, determine the recommended download, and pass that request
> onto either of the mirror networks, along with the IP address for
> locating the nearest mirror. The branch between Apache and SF mirrors
> could be done randomly, based on a tune-able parameter. if
> rand()<0.25 doApache() else doSF() would send 25% of the download
> requests to Apache, and the remaining 75% to SF.
We can certainly do this as well. Either approach is fine, but the
approach outlined above has the advantage of requiring almost no
integration work on either side -- so it would be my preference.
That said, the approach you describe here could be implemented on the
sf.net side in a day or two, so if it's your preference we're more
than happy to accomodate that.
> The nice thing about this approach is it allows each mirror network to
> do their own geographic optimization, while allowing the OpenOffice
> project to control how users are recommended a particular version of
> AOO. It allows us to maintain the matrix of downloads in one place.
> And it does not introduce any new mouse clicks for the user.
I agree that we should try to maintain the current number of clicks.
I also agree that we should give the OO project control of how the
options are presented, and I like this idea.
But the downside is that people might randomly get sf.net sometimes
and apache mirrors the next, and have an inconsistent user experience.
And I also think users should have some control over what download
experience they get.
So, overall I think Joe's suggestion of a recommended download link
that states that it's going to sourceforge.net, and a second
"alternate" link that goes the the Apache mirrors would probably
provide a better user experience.
> Is it technically feasible?
Absolutely. I think I speak for Roberto and the rest of the sf.net
team when I say we are open to whatever solution works best for the
AOO project, and are more than willing to be guided by the PPMC's
opinion on this.
--
Mark Ramm
Director of Engineering,
SourceForge Developer Experience
email: mark@geek.net
====
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.
Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
Posted by Rob Weir <ro...@apache.org>.
On Fri, Mar 23, 2012 at 10:28 AM, Roberto Galoppini <rg...@geek.net> wrote:
> Hi all,
>
> I'm resending our proposal as per previous thread 'Sourceforge and
> AOO 3.4 distribution' asking for a feedback.
>
> As Mark Ramm wrote before we could commit to delivering the full
> download volume, we wanted to produce a vetted plan, including a clear
> timeline and backing technical implementation plans.
>
> What we are proposing is an elaboration of Joe’s ‘hybrid’ approach:
>
> - Both AOO and SF.net mirror networks would be used to provide
> download capacity for the 3.4 release.
> - SourceForge.net would be the “recommended default download” on the website.
What would that look like? On what page do we make this branch? In
most of our communications we will point the public to this URL:
http://download.openoffice.org
(That then redirects to http://www.openoffice.org/download/)
The download link then provided to the user is matched to their
platform and language, based on their request headers.
Some subset (and we don't know what % since we're not running Google
Analytics here) don't want the default and click through to the full
matrix of downloads available:
http://www.openoffice.org/download/other.html
I'm assuming that we want to avoid duplicating effort maintaining the
logic for automatically matching users to the right download, as well
as avoid SF needing to tracking in detail a large matrix of downloads,
availability of new translations, etc. You just want to mirror our
dist/incubator/ooo directory.
We also want to reduce the number of clicks that stand between the
user and their download.
So where do we make the branch?
If we do it at the top level page (download.openoffice.org) then how
do you match the user to the right download, keep your page's matrix
of releases, platforms and languages in synch?
Ideally (and this is my opinion. others may have better opinions), we
would check the user's request header, get the language and platform
from that, determine the recommended download, and pass that request
onto either of the mirror networks, along with the IP address for
locating the nearest mirror. The branch between Apache and SF mirrors
could be done randomly, based on a tune-able parameter. if
rand()<0.25 doApache() else doSF() would send 25% of the download
requests to Apache, and the remaining 75% to SF.
The nice thing about this approach is it allows each mirror network to
do their own geographic optimization, while allowing the OpenOffice
project to control how users are recommended a particular version of
AOO. It allows us to maintain the matrix of downloads in one place.
And it does not introduce any new mouse clicks for the user.
Is it technically feasible?
It would be good to get Joe's or Gavin's opinion on the remainder of
Mark's note.
-Rob
> - Apache Mirror network would be an alternate download option.
> - Apache OpenOffice team and Infrastructure team will maintain
> control of the the auto-update URL’s and possibly follow Rob’s
> suggestion to stagger automatic updates.
>
>
> SourceForge.net will manage the full burst capacity for web-based
> downloads through our global network of OSS mirrors, global CDN
> network(s) and cloud file server providers. Using these resources,
> we anticipate our capacity is well above the expected delivery
> requirements for the upcoming release.
>
> In addition to basic download capacity, SourceForge will provide
> detailed download statistics, which will support future product,
> infrastructure and marketing plans. We will commit to make stats
> available on the SourceForge.net website and provide stats delivery
> APIs. We are able to capture initiated downloads, not just page
> views, and will provide them split by geography and operating system.
> We’re also willing to consider additional stats needs.
>
> Proposed Timeline:
>
> - Immediately: SourceForge sets up Apache Infra team with
> credentials on an AOO mirror project in sf.net
> - Firsr week: SourceForge updates contracts with CDN and other
> providers to handle full AOO peak release traffic
> - Second Week: AOO Infra team works with sf.net operations team to
> ramp traffic to sf.net in a controlled way in order to gather
> statistical data, verify assumptions, and give the Apache
> infrastrucure team time to verify our capacity.
> - 1-2 days post test: SF.net analyzes traffic data, assures that
> our assumptions about geographic mix, and interactive vs automated
> download mix, are valid and we can do this in a fiscally responsible
> way.
> - 1-2 days post test: AOO infrastructure team analyses traffic data,
> lets sf.net team know any additonal data needs, and validates that the
> system will work for them
>
> Once everything is tested and vetted on both sides, we will need to
> make a CDN bandwidth commit, and would like the AOO team to commit to
> notifying us 30 days prior to shutting down the flow of traffic, so
> that we can update our contracts and avoid penalties.
>
> We believe that the combination of SF.net mirrors, and CDN based burst
> capacity will provide a fast and stable download experience for AOO
> users, and will allow the AOO team to publicize the release in an
> agressive manner.
>
> Roberto
> ====
> 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.
>