Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
MIME-Version: 1.0
In-Reply-To: <526661F9.6040408@googlemail.com>
References: <526649F6.6030309@googlemail.com>
	<CAK2iWdTXk35=q=Hsf22cXN1J_C-4sxZV_oL8Cbam69EFKfW=0A@mail.gmail.com>
	<CAP-ksohGkJK0H=ctA=7PT58dOPHhjohwPmXxJAmb9H6y_G-_3Q@mail.gmail.com>
	<526661F9.6040408@googlemail.com>
Date: Tue, 22 Oct 2013 13:40:18 +0200
Message-ID: 
 <CAK2iWdQN6SKz6RAM=iWCwFTqghy3aKWXprAQD7va4pGDH47Udw@mail.gmail.com>
Subject: Re: [proposal] Patches on Windows
From: janI <jani@apache.org>
To: dev <dev@openoffice.apache.org>
Content-Type: multipart/alternative; boundary=089e011760877772e604e952ddec

--089e011760877772e604e952ddec
Content-Type: text/plain; charset=ISO-8859-1

On 22 October 2013 13:31, Andre Fischer <awf.aoo@gmail.com> wrote:

> On 22.10.2013 13:08, Rob Weir wrote:
>
>> On Tue, Oct 22, 2013 at 6:20 AM, janI <jani@apache.org> wrote:
>>
>>> On 22 October 2013 11:48, Andre Fischer <awf.aoo@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-unsubscribe@openoffice.apache.org>
>>>> >
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>>  ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<dev-unsubscribe@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<dev-unsubscribe@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

--089e011760877772e604e952ddec--