incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Thoughts on AOO release size and complexity -- Can we do better? (And what does "better" mean in this case?)
Date Wed, 16 May 2012 19:06:49 GMT
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==

<Insert your idea here>

Regards,

-Rob

Mime
View raw message