Am 16.05.12 21:06, schrieb Rob Weir: > Release = Size * Platforms * Languages > > That's the basic math we're dealing with now. Let's ignore SKD and > langpacks since they are much smaller. > > An AOO install is around 150MB. > > We currently support 6 platforms (taking into account different Linux > packaging models), and 15 languages. > > So Release = 150MB * 6 * 15 = 13.5 GB. > > Let's look at AOO 3.4.1 where we will probably add Finnish, UK > English, Norwegian and Hebrew. > > So Release = 150MB * 6 * 19 = 17.1 GB. This gets added to the > previous 13.5 GB, since we keep older releases around, or at least we > do currently. > > Imagine then future growth. Maybe Windows 64-bit, OS/2, OpenIndiana. > Imagine we get back to 44 languages supported via full installers. > Then what? > > Release = 150 MB * 9 * 44 = 59.4 GB. > > So we're not talking TB's here. But it does add up, if we want > preserve the release artifacts for earlier releases. > > Aside from storage, this is complexity for build a release. It is > more stuff to build, more stuff to schlep around people.apache.org for > release candidates, more complexity in download scripts, more stuff to > sign, more places to make mistake. Someone could make a full time job > just managing the builds and releases of this full matrix. > > Now to be fair, this matrix is optimal for the end user. 99% of the > users can download a single file and it has everything they need. No > extra things to download. And their download is as small as it can be. > It is perfect for them. > > But I wonder if we can make a radical simplification while still > making it really easy for the user? Unless of course, someone wants > to volunteer to be a full-time build engineer? > > ==Idea #1== > > Factor out the translations for the install program versus the AOO > program itself. Make the installer support all languages. > > Make core installer only have en_US resources. Everything else is > provided via language packs. > > Make the language pack be platform-neutral, e.g., resources only. > Rely on the installer that you've already downloaded for the logic to > install the language pack. > > Have the installer prompt the user at the end of the install to > install a language pack and then take them to the right webpage to > download. > > Have the installer look in the current directory for any language > packs and automatically install them at the end of the install. This > would support install fro or other places where additional downloads > are not possible. > > Pro: A full release size then becomes 150 MB x Platforms + 20MB * > Languages. So the monster case that was 59.4 GB above now becomes 2.3 > GB. > > Con: A lot of Dev work. Con2: probabily a bad user experiance. Imagin, User download OOo to the notebook, then left home and think: "I can install it later", but have no internet accass there. Even all is done fully automated it's not so comfortable as the installsets right now.
A possible solution could be that we do also download the right langpack in the same process of the binary download. and than have a offline fallback in the installer. But this makes all not less complex. > > ==Idea #2== > > Create a single multi-language install that covers whatever languages > are needed to support 99% of our users. I've heard this idea > suggested, but it doesn't really work. We have "long tail" effect > here. Even if you bundle the top 20 languages it is still only a > little over 80% of our users. In addition of inkernal update function this could maybe work. But maybe we loos performance with it. > > ==Idea #3== > > Create language installs on-demand via a cgi script. An MRU cache > would make the most common ones already ready. > > Pro: Can essentially dial in whatever space you want to allocate for > the cache. Is efficient with respect to bursty traffic, e.g., we get > a sudden appearance on the evening news in Kazakhstan. > > Con: Security aspects of cgi, and low likelihood that mirror operators > are willing to donate more CPU cycles as well. Forget this Idea, this will condum too much CPU and it's too complex for mirrors. > > ==Idea #4== > > Chill. Relax. Disk space is cheap and dropping. > > Con: It is not just disk space. It is complexity as well, especially > for our release process. > > ==Idea #5== > > <Insert your idea here> Include the possibility to have Mirrors for onle same translations. For exemple: A mirror in Argentina provide only es, us-EN and pt-BR Good thing: Users have still there installset for plattform and Lang negative: more complexity for the mirrorscript. Greetings Raphael
