openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Fischer>
Subject Re: Thoughts on AOO release size and complexity -- Can we do better? (And what does "better" mean in this case?)
Date Mon, 21 May 2012 11:57:26 GMT
On 16.05.2012 21:06, 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.
> 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.

A favor this approach but see more cons:

- For multi-user installs (admin installs for several users) you may 
need admin/super user access rights to install language packs and 

- Downloading the missing language packs is either done

-- automatically and may prompt a message from the firewall and which 
scares some users, or

-- manually (download via web browser and installation via the extension 
manager) and we loose the one-click install.

Still, I think this is the way to go.  Downloading large amounts of data 
does not seem that uncommon anymore.  With the ideas in this thread we 
can tune this from small en-US only installer that downloads basically 
everything to complete one-language and one-platform data set that does 
not need any internet connection at all.

Additionally, if we have the ability to download data on demand, we 
could use this for easy and semi-automatic (just one click) download and 
installation of additional languages, extensions, templates, designs, etc.


> ==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

View raw message