On 22 October 2013 13:31, Andre Fischer <awf....@gmail.com> wrote: > On 22.10.2013 13:08, Rob Weir wrote: > >> On Tue, Oct 22, 2013 at 6:20 AM, janI <j...@apache.org> 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 ? >>> >>> That would certainly have an even greater benefit when combined. >> >> If we don't refactor how we distribute languages we'd need many patch >> files, one for each language/platform combination. >> >> 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. >>> >>> 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. >>>> >>>> >> At some point we'd need to think about how users find and get these >> patches. The current mechanism notifies them about the update and >> sends them to www.openoffice.org/download or to an NL page. The >> Javascript logic recommends what download to get. We'd need to >> distinguish new downloads from patches. >> > > The update notifications could link directly to patches when notifying a > minor or micro release. After all, they originate from an installed office. > > Only users that go to our download page have to make a choice between full > installation and patch. > > > >> Also, perhaps complications if someone has installed AOO with lang A + >> lang pack B. How is this patched? There is a huge number of >> combinations there. Jan's idea of a combined 200MB install with all >> languages sounds simpler, though larger. >> > > Maybe I should point out that the creation of installation and patch sets > on Windows is an amazingly complex task, even for the current single > language install. Then, as I have said already in an earlier mail, we have > to distinguish between > > > - UI language of the installer > - UI language of OpenOffice > - supported languages for spell checking etc. > > > I don't know much about language support of installer and patches but I > see a problem with spell checking. Spell checking and grammar checking is > done by extensions which have to be registered at first start. That can > not be done directly by the installer or a patch. They can at best trigger > such a registration at first start. And the whole area of first start and > extension registration is a really dark area of our code. > I would like to first try to get the patch creation to work for single > language installs and then we can think about how to handle multiple > languages. > > +1 keep it simple, but keep multiple languages in mind, I think we very soon need to address that issue.
I dont understand "first start", I just added a new spell checker to my running AOO so I would think it can be done anytime. rgds jan I. > -Andre > > > >> Regards, >> >> -Rob >> >> >> 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. >>> >>> >>> >>>> 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. >>> >>> 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 >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
