see idea #5 below
On 5/16/2012 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.
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.
==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.
==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.
==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==
Two changes
- create an installer that works from a local file system (or CD) that
installs all of the signed and well formed artifacts in the fs. This
means that it will install base AOO, language packs, extensions
(dictionaries) , and templates.
- create a bootstrap installer that will download the appropriate bits
from the interwebs to your local fs and then kick off the install.
Pro:
- has lower disk footprint in archives and limits download bandwidth
to required bits
- provides seamless install experience for user whether from web,
local fs, or cd.
- improved install experience, as extensions, templates, extra
languages, etc can be added into the base install seamlessly.
- allows for value add downstream packaging - with dictionaries,
extensions, etc. Once the file structure is created it can easily be
written to media, thus custom install on a cd.
- with proper design on bootstrap installer, the download can be
optimized (compression, restartability, etc)
Cons:
- it is only ideaware at the moment
<Insert your idea here>
Regards,
-Rob
