Hello, 2009.04.15 20:28, Florian Effenberger rašė: >> Thanks for this numbers - and just to be precise and understand the >> restrictions correctly: the limit is not set by our infrastructure, >> but has been agreed with the mirror admins? Means - if we would like >> to use more space at the mirrors we would need to ask the mirror >> admins (if they gree or not, is out of our control, I'd guess). > > the limit is determined by our infrastructure as well as our mirror > admins. > > In the infrastructure, we need a machine capable of hosting all the > files. If its volume is limited to 150 GB, no more than 150 GB can be > distributed to the mirrors. However, disk space is cheap nowadays, so > that's not a real issue if we invest some money out of the budget.
So, in theory, it shouldn't be that hard to have one or two master servers hosting let's say, a terabyte of data, right? > The other problem is the space on the mirrors itself. Not many mirrors > can offer so much space for a single project. Even if one or two > mirrors could, that wouldn't be enough for our downloads. We need at > least a dozen mirrors or so capable of hosting 150, 200, 250 ... GB - > and that's the real problem. > > The only chance I see is to ask the extended mirrors (who already > agreed in providing more mirror space than "normal" mirrors). But I > doubt we get lots of them offering us 150+ GB... I think what would make sense is the following: 1) to have a consistent directory structure (i.e. the location of this version builds in this language should be predictable) on master servers. While looking at our project page [http://distribution.openoffice.org/files.html#sets], everything seems very clear already: ALL QA'd localized binaries should go to /localized/, while unQA'd files go to /extended/localized/. That makes sense. I guess our project's problem is that we failed to accept the fact that with growing number of supported languages, the size of /localized/ (and thus sets that include it) also grows. Maybe it's time to face it... By the way, currently /localized/ uses 19GB, meanwhile at least for the last year the aforementioned page says it is about 30GB. I wonder how QA'd builds got into /extended/localized/ at all... I just adjusted my script to fetch this whole folder, so I hope to see how much all our QA'd builds actually take up now. 2) for space-concerned mirrors to mirror localized builds selectively. For example, in my mirror in Lithuania, I currently host all builds from /localized/ and en-US, Lithuanian, Latvian, Polish, and Russian files from /extended/. I could surely add more languages (esp. from neighbouring countries) to the list if I face a demand. To help reduce the headache for mirror admins, we could group localizations logically into sets (and maybe subsets). E.g., the set I host could be a part of "Eastern Europe" set. 3) this should work very well when combined with geographical mirror allocation, since local mirrors would be getting most of the request for certain language builds anyway. I think the number of servers in a given country is proportional to the number of users in that country, so for smaller countries it's OK to have less/slower servers, meanwhile bigger and more advanced countries would have more and faster servers anyway. 4) Openoffice should strive to provide as many localized installers as possible. I'm not sure about how many resources we need or have, but I can (as always) point at Mozilla as an example, where each time a localizer commits changes to Mercurial (which replaced CVS), in about 15 minutes they get a bunch of fresh builds of the affected program (Firefox or Thunderbird works best, so far) in ftp.mozilla.org – for all three supported platforms. >From my POV, language packs are second class citizens. They take additional time and effort to discover and install, and should not be the only way to get OOo in your language. Rimas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@l10n.openoffice.org For additional commands, e-mail: dev-h...@l10n.openoffice.org
