Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
On 26 March 2012 17:22, Rob Weir robw...@apache.org wrote: On Sun, Mar 25, 2012 at 9:20 AM, Mark Ramm m...@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
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 rgard...@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 robw...@apache.org wrote: On Sun, Mar 25, 2012 at 9:20 AM, Mark Ramm m...@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
- 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: m...@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
Re: Feedback Requested: Proposed SourceForce Mirror of AOO 3.4
On Fri, Mar 23, 2012 at 10:28 AM, Roberto Galoppini rgalopp...@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
