On Apr 27, 2012, at 2:14 PM, Rob Weir wrote: > On Fri, Apr 27, 2012 at 5:01 PM, Dave Fisher <dave2w...@comcast.net> wrote: >> >> On Apr 27, 2012, at 1:46 PM, Rob Weir wrote: >> >>> On Fri, Apr 27, 2012 at 4:31 PM, Andrea Pescetti <pesce...@apache.org> >>> wrote: >>>> Kay Schenk wrote: >>>>> >>>>> Please take a look at and give feedback on a test page for the new >>>>> /download/index.html page at: >>>>> http://www.openoffice.org/download/test/index_new_dl.html >>>>> Yes, it's a bit strange with lots of nonsense at the top that I wanted >>>>> you to see, but will of course go away in production. >>>> >>>> >>>> The page is nice, but it's the concept that leaves me dubious. >>>> >>>> We have another thread >>>> http://comments.gmane.org/gmane.comp.apache.incubator.ooo.devel/16219 >>>> where there seems to be consensus towards a solution that: >>>> 1) Uses SF (and possibly Apache) for the web-based downloads >>>> 2) Does not phase out MirrorBrain, and uses it for the updates (i.e., >>>> downloads initiated by OpenOffice with the "Look for updates" function) >>>> >>> >>> That's what I understand as well. >>> >>>> The "possibly Apache" in 1) is due to the fact that I haven't understood >>>> yet >>>> what technology Apache will be using and if Apache will distribute only >>>> sources or binaries too (it's obvious that we as a project will release >>>> sources and binaries, but I'm not 100% sure that Apache wants to put >>>> binaries on its mirrors too: I think so). >>>> >>>> Fact is, we should avoid the random selection as much as possible, mainly >>>> to >>>> be able to quickly identify problems, and you will see details in that >>>> thread. The cleaner separation we can get, the better. >>>> >>> >>> So how about something very simple: >>> >>> 1) AOO 3.4 downloads use SourceForge by default from the >>> /download/index.html page. Just like they are doing today. >>> >>> But we also have a links there that point to Apache mirrors for: >>> >>> a) Hashes and detached signatures >> >> Hashes and detached signatures are hosted elsewhere in Apache releases. Not >> on the mirrors. >> http://poi.apache.org/download.html >> http://tomcat.apache.org/download-60.cgi >> http://httpd.apache.org/download.cgi >> >> Joe has suggested that we follow a cgi approach for Apache mirrors. Kay >> asked for help with this approach. I hope to have time next Monday/Tuesday >> to dialog with Infra on this. >> >>> b) source distribution >>> c) a link to the full release tree >>> >>> In other words, no rolling the dice, noting fancy. 100% of normal >>> users will download from SF. >> >> What Kay has done can be adapted in any direction. Let's learn how to do the >> Apache CGI approach and then make a decision by Tuesday? >> > > Do we really want to beta test new Apache CGI code? Or do we want to > go with what we've been testing live since April 11th, namely SF.
I personally want to test the Apache CGI method. Kay asked for help. I won't consider my time to be wasted whether it is used by the project or not. >> If we allow more than one mirroring system then the user should be able to >> choose for themselves... >> > > Users want a download that works. They have no reason to chose from > equally opaque alternatives. You are suggesting a single mirror - SF. I only suggested that users be offered a choice if we have more than one mirror available. It would also really help to have a choice on the TEST page until everyone is happy. It can only be good to have alternative mirrors tested. Whether or not users get that choice. > >> BUt we already have Marcus, Rob, Kay, Peter, Infra and SF cooking in this >> kitchen. We can't keep redefining the problem. >> > > I'd say stick with SourceForge as we originally agreed to. Remember, > they need to balance their books on the traffic. They did the > analysis, and incurred initial costs. This was based on assumptions > of traffic that they would be handling. Don't assume that giving them > less traffic saves them money. It might actually do the opposite, > especially if they have contracted for the bandwidth and now find they > are serving up far few ads because our "cooks" have decided to play > with MirrorBrain or whatever. I was not thinking one way or another about SF's business model. It is merely a technical issue. > We should be a good partner here and stick to what we agreed with. > Otherwise, if we start being flaky, we're less likely to see such help > in the future. As I said "We can't keep redefining the problem." But let's be sure we are on target. Marcus, Kay and Roberto along with you, Rob, have been doing this work. I'm trying to stay out of the way here. Regards, Dave > > -Rob > > >> Regards, >> Dave >> >>> >>> 2) When we enable the automated updates, in a week or two, then we >>> decide what we want to do. Maybe we do it via SF. Maybe MirrorBrain. >>> Maybe a mix, >>> >>>> On the other side, release time is approaching and I can only hope that >>>> talks between Peter Poeml (MirrorBrain author) and Apache Infra, that had >>>> started on this list, are progressing now. >>>> >>> >>> I think it is too late for any of those talks to influence how we deal >>> with AOO 3.4 initial downloads. But maybe the update downloads in a >>> couple of weeks. >>> >>> -Rob >>> >>>> Regards, >>>> Andrea. >>
