incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphael Bircher <rbirc...@apache.org>
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:34:38 GMT
Am 16.05.12 21:06, schrieb Rob Weir:
> 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.
Con2: probabily a bad user experiance. Imagin, User download OOo to the
notebook, then left home and think: "I can install it later", but have
no internet accass there. Even all is done fully automated it's not so
comfortable as the installsets right now.

A possible solution could be that we do also download the right langpack
in the same process of the binary download. and than have a offline
fallback in the installer. But this makes all not less complex.
>
> ==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.

In addition of inkernal update function this could maybe work. But maybe
we loos performance with it.
>
> ==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.
Forget this Idea, this will condum too much CPU and it's too complex for
mirrors.
>
> ==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>
Include the possibility to have Mirrors for onle same translations. For
exemple: A mirror in Argentina provide only es, us-EN and pt-BR

Good thing: Users have still there installset for plattform and Lang

negative: more complexity for the mirrorscript.


Greetings Raphael

Mime
View raw message