incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: 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:25:31 GMT

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 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,
> -Rob

View raw message