You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Rob Weir <ro...@apache.org> on 2012/05/16 21:06:49 UTC
Thoughts on AOO release size and complexity -- Can we do better? (And
what does "better" mean in this case?)
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==
<Insert your idea here>
Regards,
-Rob
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Fernando Cassia <fc...@gmail.com>.
On Wed, May 16, 2012 at 4:06 PM, Rob Weir <ro...@apache.org> wrote:
> ==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.
>
>
I vote for idea #1. The installer should read the language of the OS its
running on (easy on windows, unknown how to do that in Linux-BSD-Unix and
present dialogs in that language, along with bitmaps during the install
process (if any). Then, the US-English release should be installed, and any
additional languages needed should be downloaded after the fact, the first
time the app is run (if "detected OS language is different from US
english", or as a second step after installation.
Now, of course it is easier said than done. ;) Or "everything works, in
theory". ;)
FC
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Raphael Bircher <rb...@apache.org>.
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
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Andre Fischer <af...@a-w-f.de>.
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 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.
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
extensions.
- 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.
Regards,
Andre
>
> ==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
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Ji Yan <ya...@gmail.com>.
How about we built base installer for each platform with EN resource, and
make language resource, including UI translation, translated help and
corresponding dictionary, as extension which can be download from internet.
Make sure the language pack is platform independ so the total package size
will be reduced.
2012/5/17 Kevin Grignon <ke...@gmail.com>
> Hello All,
>
> This is an important issue. Single click installation is expectation of the
> market place that cannot be ignored.
>
> That said, we are not an mobile app, and desktop applications require
> additional installation configuration by the end user.
>
> With regards to language pack, I'll leave the back end to the development
> folks.
>
> From a UX perspective, we might consider the following:
>
> - allow the users to single click to install the application using smart
> default configuration (install location, default language pack, default
> values, etc.)
> - progressively disclose secondary installation requirements, such as
> language packs
>
> There are two paths we could explore here:
>
> 1 - have language selection as part of install
> - the user could select the languages they want, and we download and
> install in background
> - we should not send people to find installation files for a second, manual
> install
>
> 2 - prompt for additional languages when the user opens the app for the
> first time
> - again, download and install in the background
>
> Finally, a user should be able to manage the languages from within the
> product itself. Here again, we take care of downloads, unpacking and
> installation behind the scenes. Yes, we support many languages and
> platforms, this is our choice and we should not burden our end users with
> this complexity. I suspect most user just want to install their platform,
> select their language pack, and get to work. Let's help them do jsut that.
>
> Some thoughts...
>
> Regards,
> Kevin
>
>
> On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rbircher@apache.org
> >wrote:
>
> > 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.orgfor
> > >> 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
> > >
> >
> >
>
--
Thanks & Best Regards, Yan Ji
Re: Thoughts on AOO release size and complexity -- Can we do better? (And what does "better" mean in this case?)
Posted by Jan Høydahl <ja...@cominvent.com>.
To know how this should impact our planning, it would be wise to understand the respective app stores better. I only know the Apple store from a user perspective so I wouldn't know how much magic you can do during install or if it's just a plain copy of the .app bundle. And I don't know anything tech about Windows store in Win8.
Jan
Den 18. mai 2012 kl. 11:48 skrev Kevin Grignon <ke...@gmail.com>:
> Well said.
>
>
>
> On Fri, May 18, 2012 at 5:45 PM, Jan Høydahl <ja...@cominvent.com> wrote:
>
>>> This is an important issue. Single click installation is expectation of
>> the
>>> market place that cannot be ignored.
>> +1
>>
>> Also keep in mind that both Apple and Microsoft are moving towards 1-click
>> installs from App stores as the new default, so in a few years new PC/Mac
>> users (such as students) will never even look outside of the app store when
>> looking for programs.
>>
>> This calls for a single multi lingual AOO installer which "does the right
>> thing" without user input. That "thing" would be looking up users default
>> language, download the corresponding lang pack (remember that user is
>> necessarily connected to Internet when installing from app store) and
>> install it. Next time user starts the app he can be prompted for additional
>> langs.
>>
>> Jan
>>
>> Den 17. mai 2012 kl. 05:24 skrev Kevin Grignon <kevingrignon.oo@gmail.com
>>> :
>>
>>> Hello All,
>>>
>>> This is an important issue. Single click installation is expectation of
>> the
>>> market place that cannot be ignored.
>>>
>>> That said, we are not an mobile app, and desktop applications require
>>> additional installation configuration by the end user.
>>>
>>> With regards to language pack, I'll leave the back end to the development
>>> folks.
>>>
>>> From a UX perspective, we might consider the following:
>>>
>>> - allow the users to single click to install the application using smart
>>> default configuration (install location, default language pack, default
>>> values, etc.)
>>> - progressively disclose secondary installation requirements, such as
>>> language packs
>>>
>>> There are two paths we could explore here:
>>>
>>> 1 - have language selection as part of install
>>> - the user could select the languages they want, and we download and
>>> install in background
>>> - we should not send people to find installation files for a second,
>> manual
>>> install
>>>
>>> 2 - prompt for additional languages when the user opens the app for the
>>> first time
>>> - again, download and install in the background
>>>
>>> Finally, a user should be able to manage the languages from within the
>>> product itself. Here again, we take care of downloads, unpacking and
>>> installation behind the scenes. Yes, we support many languages and
>>> platforms, this is our choice and we should not burden our end users with
>>> this complexity. I suspect most user just want to install their platform,
>>> select their language pack, and get to work. Let's help them do jsut
>> that.
>>>
>>> Some thoughts...
>>>
>>> Regards,
>>> Kevin
>>>
>>>
>>> On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rbircher@apache.org
>>> wrote:
>>>
>>>> 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.orgfor
>>>>>> 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
>>>>>
>>>>
>>>>
>>
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Kevin Grignon <ke...@gmail.com>.
Well said.
On Fri, May 18, 2012 at 5:45 PM, Jan Høydahl <ja...@cominvent.com> wrote:
> > This is an important issue. Single click installation is expectation of
> the
> > market place that cannot be ignored.
> +1
>
> Also keep in mind that both Apple and Microsoft are moving towards 1-click
> installs from App stores as the new default, so in a few years new PC/Mac
> users (such as students) will never even look outside of the app store when
> looking for programs.
>
> This calls for a single multi lingual AOO installer which "does the right
> thing" without user input. That "thing" would be looking up users default
> language, download the corresponding lang pack (remember that user is
> necessarily connected to Internet when installing from app store) and
> install it. Next time user starts the app he can be prompted for additional
> langs.
>
> Jan
>
> Den 17. mai 2012 kl. 05:24 skrev Kevin Grignon <kevingrignon.oo@gmail.com
> >:
>
> > Hello All,
> >
> > This is an important issue. Single click installation is expectation of
> the
> > market place that cannot be ignored.
> >
> > That said, we are not an mobile app, and desktop applications require
> > additional installation configuration by the end user.
> >
> > With regards to language pack, I'll leave the back end to the development
> > folks.
> >
> > From a UX perspective, we might consider the following:
> >
> > - allow the users to single click to install the application using smart
> > default configuration (install location, default language pack, default
> > values, etc.)
> > - progressively disclose secondary installation requirements, such as
> > language packs
> >
> > There are two paths we could explore here:
> >
> > 1 - have language selection as part of install
> > - the user could select the languages they want, and we download and
> > install in background
> > - we should not send people to find installation files for a second,
> manual
> > install
> >
> > 2 - prompt for additional languages when the user opens the app for the
> > first time
> > - again, download and install in the background
> >
> > Finally, a user should be able to manage the languages from within the
> > product itself. Here again, we take care of downloads, unpacking and
> > installation behind the scenes. Yes, we support many languages and
> > platforms, this is our choice and we should not burden our end users with
> > this complexity. I suspect most user just want to install their platform,
> > select their language pack, and get to work. Let's help them do jsut
> that.
> >
> > Some thoughts...
> >
> > Regards,
> > Kevin
> >
> >
> > On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rbircher@apache.org
> >wrote:
> >
> >> 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.orgfor
> >>>> 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
> >>>
> >>
> >>
>
Re: Thoughts on AOO release size and complexity -- Can we do better? (And what does "better" mean in this case?)
Posted by Jan Høydahl <ja...@cominvent.com>.
> This is an important issue. Single click installation is expectation of the
> market place that cannot be ignored.
+1
Also keep in mind that both Apple and Microsoft are moving towards 1-click installs from App stores as the new default, so in a few years new PC/Mac users (such as students) will never even look outside of the app store when looking for programs.
This calls for a single multi lingual AOO installer which "does the right thing" without user input. That "thing" would be looking up users default language, download the corresponding lang pack (remember that user is necessarily connected to Internet when installing from app store) and install it. Next time user starts the app he can be prompted for additional langs.
Jan
Den 17. mai 2012 kl. 05:24 skrev Kevin Grignon <ke...@gmail.com>:
> Hello All,
>
> This is an important issue. Single click installation is expectation of the
> market place that cannot be ignored.
>
> That said, we are not an mobile app, and desktop applications require
> additional installation configuration by the end user.
>
> With regards to language pack, I'll leave the back end to the development
> folks.
>
> From a UX perspective, we might consider the following:
>
> - allow the users to single click to install the application using smart
> default configuration (install location, default language pack, default
> values, etc.)
> - progressively disclose secondary installation requirements, such as
> language packs
>
> There are two paths we could explore here:
>
> 1 - have language selection as part of install
> - the user could select the languages they want, and we download and
> install in background
> - we should not send people to find installation files for a second, manual
> install
>
> 2 - prompt for additional languages when the user opens the app for the
> first time
> - again, download and install in the background
>
> Finally, a user should be able to manage the languages from within the
> product itself. Here again, we take care of downloads, unpacking and
> installation behind the scenes. Yes, we support many languages and
> platforms, this is our choice and we should not burden our end users with
> this complexity. I suspect most user just want to install their platform,
> select their language pack, and get to work. Let's help them do jsut that.
>
> Some thoughts...
>
> Regards,
> Kevin
>
>
> On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rb...@apache.org>wrote:
>
>> 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
>>>
>>
>>
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Kevin Grignon <ke...@gmail.com>.
Hello All,
This is an important issue. Single click installation is expectation of the
market place that cannot be ignored.
That said, we are not an mobile app, and desktop applications require
additional installation configuration by the end user.
With regards to language pack, I'll leave the back end to the development
folks.
>From a UX perspective, we might consider the following:
- allow the users to single click to install the application using smart
default configuration (install location, default language pack, default
values, etc.)
- progressively disclose secondary installation requirements, such as
language packs
There are two paths we could explore here:
1 - have language selection as part of install
- the user could select the languages they want, and we download and
install in background
- we should not send people to find installation files for a second, manual
install
2 - prompt for additional languages when the user opens the app for the
first time
- again, download and install in the background
Finally, a user should be able to manage the languages from within the
product itself. Here again, we take care of downloads, unpacking and
installation behind the scenes. Yes, we support many languages and
platforms, this is our choice and we should not burden our end users with
this complexity. I suspect most user just want to install their platform,
select their language pack, and get to work. Let's help them do jsut that.
Some thoughts...
Regards,
Kevin
On Thu, May 17, 2012 at 4:23 AM, Raphael Bircher <rb...@apache.org>wrote:
> 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
> >
>
>
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Raphael Bircher <rb...@apache.org>.
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
>
Re: Thoughts on AOO release size and complexity -- Can we do better?
(And what does "better" mean in this case?)
Posted by Andrew Rist <an...@oracle.com>.
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
Re: Thoughts on AOO release size and complexity -- Can we do better? (And what does "better" mean in this case?)
Posted by Dave Fisher <da...@comcast.net>.
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 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.
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,
Dave
>
> Regards,
>
> -Rob