On 22 October 2013 13:10, Andre Fischer <awf....@gmail.com> wrote: > On 22.10.2013 12:20, janI wrote: > >> On 22 October 2013 11:48, Andre Fischer <awf....@gmail.com> wrote: >> >> Hello everybody, >>> >>> At the moment we provide full installation sets for every release and for >>> all platforms and languages. An installation set has a typical size of >>> roughly 150MB. The size of the actual changes is typically much smaller. >>> Using patches instead of full installation sets would considerably >>> reduce >>> the amount of data that has to be downloaded by users. For new users >>> without existing installation of OpenOffice we probably still need the >>> full >>> installation sets. >>> >>> Would this also be an opertunity, to look at how we release languages ? >> >> I have tested making an installation set that contain all released >> languages, it has a rough size of 200Mb, which is a lot friendlier than <# >> langauges> * 150Mb, and gives international users (like me) the option to >> switch UI. >> > > Friendlier to our servers, but not to our users. But this problem is > orthogonal to creating patches. And we have to distinguish what language > support we are talking about: > - UI language of the installer > We still need the installer in every language, and that the bit that I have not done. I envised a fork in the installer so it loads the OS language of the host.
> - UI language of OpenOffice > that is what I have done with --with-lang > - Languages supported by spell checker et al. that is simple files added to the distribution, and the main reason for the extra 50Mb. Why do you see this as a disadvantage to our users. Many users have multiple languages for spell checkers etc installed, and some (especially people working internationally) also have multiple UI languages. rgds jan I. > > > >> All I miss is to pursuade the installer to choose the right default UI >> language. >> >> >> >> Note that such patches can only be made for minor or micro releases. >>> Major releases would still be full installation sets. >>> >>> I have worked in the past months on finding out how our build system has >>> to be modified in order to create patch sets on Windows. This has >>> resulted >>> in a set of conditions [1] that have to be fulfilled by the installation >>> sets. One example of a condition that we currently don't fulfill is that >>> files must not be deleted in minor or micro releases. >>> >>> Up to now I have taken two full installation sets and then tweaked the >>> newer one until I was able to >>> a) successfully create an .msp patch file and >>> b) successfully apply it to an OpenOffice that was installed by the older >>> install set. >>> >>> I would now like to change the build system, especially the solenv/bin/ >>> make_installer.pl script and its modules, so that the installation sets >>> it creates can be used without further changes to create patch sets. I >>> would also like to add the patch creation itself. >>> >>> +1, I have added a single comment on the wiki page about zero length >> files. >> >> please consider making the patch mechanism in its own module. >> >> >> For this I propose and seek lazy consensus for the following changes: >>> >>> 1. When a new release is made, create data files that are added to our >>> version control system (semi automatically) that allow us on the next >>> release to check and/or enforce the conditions. >>> >>> 2. Before the next release is made, read the data files of the previous >>> release and check and/or enforce the conditions. >>> >>> 3. When a new minor or micro release is made, first create the full >>> installation sets, then create patches. >>> Besides the data files mentioned above, this also requires access to >>> the installation sets of the previous release. >>> >>> 4. Cleanup of the logging mechanism used by make_installer.pl and its >>> modules, so that I can better debug the existing and the new code. >>> >>> >>> Most of the proposed changes have a low impact on the current creation of >>> installation sets. They basically only add new features (collecting >>> information about a release, adding it to the VCS, reading the >>> information >>> on next release, checking conditions, creating patches). However, some >>> conditions can be enforced automatically (like using the same uuids for >>> components in one release and the next) and that can introduce >>> regressions, >>> ie break installation sets. But I think the danger of that is not bigger >>> than with many other new features or bug fixes. I don't expect conflicts >>> with build system changes made or proposed by Jan. >>> >>> Go for it, if you do in trunk, I can merge it into my branches. >> >> I also very little conflict with my build system work, like maybe 1-2 >> changed makefiles. But thats no serious conflicts, and more me being aware >> of the changes. >> > > Thanks. When I eventually check in the changes I will report the details. > > > >> >> >>> More details about the creation of installation sets and patches can be >>> found in the Wiki [2]. >>> >>> I really like the idea, that brings us one step closer to a more >> installation. >> > > Thanks. After I looked at the make_installer.pl script I toyed with the > idea of reimplementing it completely. But that would require too much > time. So I will cope with 40 characters long identifiers like '$** > scpactionsinproductlanguageres**olvedarrayref'. But maybe I will clean > up things like sort algorithms that make bubblesort look fast (see > sorting_array_of_hashes() in > solenv/bin/modules/installer/s**orter.pm<http://sorter.pm>). > That are 20 lines of bad code that can be replaced by a single short line > of Perl code that is much more expressive. > > -Andre > > >> thx for taking this initative. >> >> rgds >> jan I. >> >> >> Regards, >>> Andre >>> >>> >>> [1] >>> http://wiki.openoffice.org/****wiki/Building_installation_**<http://wiki.openoffice.org/**wiki/Building_installation_**> >>> packages#Conditions_for_****creating_patches<http://wiki.** >>> openoffice.org/wiki/Building_**installation_packages#** >>> Conditions_for_creating_**patches<http://wiki.openoffice.org/wiki/Building_installation_packages#Conditions_for_creating_patches> >>> > >>> [2] http://wiki.openoffice.org/****wiki/Building_installation_**** >>> packages<http://wiki.openoffice.org/**wiki/Building_installation_**packages> >>> <http://wiki.**openoffice.org/wiki/Building_**installation_packages<http://wiki.openoffice.org/wiki/Building_installation_packages> >>> > >>> >>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@openoffice.**a**pache.org<http://apache.org> >>> <dev-unsubscribe@**openoffice.apache.org<dev-unsubscr...@openoffice.apache.org> >>> > >>> >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
