Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of andrew.rist@oracle.com
 designates 141.146.126.227 as permitted sender)
Message-ID: <4FB405C4.7060407@oracle.com>
Date: Wed, 16 May 2012 12:53:40 -0700
From: Andrew Rist <andrew.rist@oracle.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Thoughts on AOO release size and complexity -- Can we do better?
 (And what does "better" mean in this case?)
References: 
 <CAP-ksojKY_JPdFezjNM5YjqjA-QEB_0bLbtrv6C+HwSwq0srPg@mail.gmail.com>
In-Reply-To: 
 <CAP-ksojKY_JPdFezjNM5YjqjA-QEB_0bLbtrv6C+HwSwq0srPg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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