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 20:23:59 GMT
Am 16.05.12 21:53, schrieb Andrew Rist:
> 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
You need internet or you have a ugly puzzle.

Sure, it's the easyest way, but i beleve not the best.
>
>
>>
>> <Insert your idea here>
>>
>> Regards,
>>
>> -Rob
>


Mime
View raw message