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 >
