On May 16, 2012, at 12:06 PM, Rob Weir wrote: > 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.
Like in a directory on an installation thumb-drive. > > 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. This can make it much easier to include future OS ports as official releases. This would allow out of band language pack releases. > > > Con: A lot of Dev work. This is really in the proper direction and I like the idea. > > ==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. This prevents ad hoc language pack releases. > > ==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. Ugh. We can't make installation of obscure language packs completely dependent on the internet. > > ==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. Agreed. Very complex. > > ==Idea #5== > > <Insert your idea here> It would only be a variation on Idea #1. Regards, Dave > > Regards, > > -Rob
