You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Andre Fischer <aw...@gmail.com> on 2013/10/22 11:48:38 UTC
[proposal] Patches on Windows
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.
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.
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.
More details about the creation of installation sets and patches can be
found in the Wiki [2].
Regards,
Andre
[1]
http://wiki.openoffice.org/wiki/Building_installation_packages#Conditions_for_creating_patches
[2] http://wiki.openoffice.org/wiki/Building_installation_packages
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 23.10.2013 09:19, Andre Fischer wrote:
> On 22.10.2013 23:49, Andrea Pescetti wrote:
>> Andre Fischer wrote:
>>> 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.
>>
>> This is another feature that users have asked for several years, great
>> to see progress here!
>>
>>> More details about the creation of installation sets and patches can be
>>> found in the Wiki [2].
>>
>> A question I have is what happens to the versionrc file (or equivalent
>> on Windows). It contains hard-coded (but customizable at the system
>> level) defaults for, e.g., the update URL. Will applying the patch
>> overwrite it too?
>
> Good point but no, the patch can only modify files in the 'Program Files
> (x86)' directory and registry entries in the registry.
> Well, there are the custom actions (dlls provided by us that can
> basically do anything) that might allow us to modify the versionrc
> file. But that is a second step.
> Alternatively we can move the URL into the registry and use the one in
> versionrc as a fallback on non-Windows platforms.
>
the file 'versionrc' resp. 'version.ini' is part of our installation
package. It is found in our 'program' folder of our installation.
As this file belongs to the installation I assume that it will be
treated as any other file of our installation. Thus, it will be
overwritten by the installation of the patch. Andre, please correct me,
if I am wrong.
In short:
The result of the installation of the patch package must be the same as
the result of the installation of the full package.
Best regards, Oliver.
>>
>> On one hand, leaving it as it is would create problems since
>> OpenOffice would continue to behave as the old version when looking
>> for updates. On the other hand, overwriting it would destroy user
>> customizations; but this is probably what we are already doing now for
>> full installation sets.
>
> I would expect that overwriting is not done during the installation but
> when the OpenOffice is started the first time after that. That first
> start procedure can also be triggered after a patch is applied.
>
> -Andre
>
>>
>> Regards,
>> Andrea.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by Andre Fischer <aw...@gmail.com>.
On 22.10.2013 23:49, Andrea Pescetti wrote:
> Andre Fischer wrote:
>> 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.
>
> This is another feature that users have asked for several years, great
> to see progress here!
>
>> More details about the creation of installation sets and patches can be
>> found in the Wiki [2].
>
> A question I have is what happens to the versionrc file (or equivalent
> on Windows). It contains hard-coded (but customizable at the system
> level) defaults for, e.g., the update URL. Will applying the patch
> overwrite it too?
Good point but no, the patch can only modify files in the 'Program Files
(x86)' directory and registry entries in the registry.
Well, there are the custom actions (dlls provided by us that can
basically do anything) that might allow us to modify the versionrc
file. But that is a second step.
Alternatively we can move the URL into the registry and use the one in
versionrc as a fallback on non-Windows platforms.
>
> On one hand, leaving it as it is would create problems since
> OpenOffice would continue to behave as the old version when looking
> for updates. On the other hand, overwriting it would destroy user
> customizations; but this is probably what we are already doing now for
> full installation sets.
I would expect that overwriting is not done during the installation but
when the OpenOffice is started the first time after that. That first
start procedure can also be triggered after a patch is applied.
-Andre
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by Andrea Pescetti <pe...@apache.org>.
Andre Fischer wrote:
> 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.
This is another feature that users have asked for several years, great
to see progress here!
> More details about the creation of installation sets and patches can be
> found in the Wiki [2].
A question I have is what happens to the versionrc file (or equivalent
on Windows). It contains hard-coded (but customizable at the system
level) defaults for, e.g., the update URL. Will applying the patch
overwrite it too?
On one hand, leaving it as it is would create problems since OpenOffice
would continue to behave as the old version when looking for updates. On
the other hand, overwriting it would destroy user customizations; but
this is probably what we are already doing now for full installation sets.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by Andre Fischer <aw...@gmail.com>.
On 22.10.2013 13:40, janI wrote:
> On 22 October 2013 13:31, Andre Fischer <aw...@gmail.com> wrote:
>
>> 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.
>
>
You, and every user can, but not the installer or a patch. The
installer relies on OpenOffice to check on its first start if there are
any extensions that have to be installed. The same might work after
applying a patch.
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by janI <ja...@apache.org>.
On 22 October 2013 13:31, Andre Fischer <aw...@gmail.com> wrote:
> On 22.10.2013 13:08, Rob Weir wrote:
>
>> On Tue, Oct 22, 2013 at 6:20 AM, janI <ja...@apache.org> wrote:
>>
>>> On 22 October 2013 11:48, Andre Fischer <aw...@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>
>>>> <de...@openoffice.apache.org>
>>>> >
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [proposal] Patches on Windows
Posted by Andre Fischer <aw...@gmail.com>.
On 22.10.2013 13:08, Rob Weir wrote:
> On Tue, Oct 22, 2013 at 6:20 AM, janI <ja...@apache.org> wrote:
>> On 22 October 2013 11:48, Andre Fischer <aw...@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.
-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_**
>>> 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>
>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by Rob Weir <ro...@apache.org>.
On Tue, Oct 22, 2013 at 6:20 AM, janI <ja...@apache.org> wrote:
> On 22 October 2013 11:48, Andre Fischer <aw...@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.
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.
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_**
>> 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>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by janI <ja...@apache.org>.
On 22 October 2013 13:48, Andre Fischer <aw...@gmail.com> wrote:
> On 22.10.2013 13:32, janI wrote:
>
>> On 22 October 2013 13:10, Andre Fischer <aw...@gmail.com> wrote:
>>
>> On 22.10.2013 12:20, janI wrote:
>>>
>>> On 22 October 2013 11:48, Andre Fischer <aw...@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.
>>
>
> There are two parts to this: setup.exe and the included msi. Adding
> support to the msi might be easier than we think. At least the 'File'
> table has a 'Language' column. I think the table that contains the UI
> messages that are displayed during the installation has something similar.
> If this column acts as a filter then all we have to do is add entries for
> all languages and let the msi select the right ones automatically. The
> setup.exe is build by the NSIS installer creator. I don't know if and how
> it supports multiple languages.
>
>
>
>> - 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.
>>
>
> Yes, but how do we decide which of the many spell checkers to install?
> All of them all the time? Or only a subset, depending on the locale?
You are right, we might just want to install the UI part with the local
spell checker, then the user can choose to add spell checkers as needed.
>
>
>
>> Why do you see this as a disadvantage to our users.
>>
>
> I only see the larger download as disadvantage. I don't know how many
> people really would want to have even more spell checkers installed on
> their system and would accept an increase of 1/3 of our already large
> installation sets.
> The main reason for using patches instead of full installation sets is
> their reduced size. Including all available languages might reduce that
> advantage.
>
You misunderstand me. I am 100% for patches !!
with all available languages in the install set, we will only need 1 patch,
so in total its an advantage.
But as said earlier, I agree with "small steps" first make the patches
work, then consider the rest.
rgds
jan I.
>
> -Andre
>
>
>> 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_**>
>>>>> **<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#**<http://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_******<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 <http://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<http://openoffice.apache.org>
>>>>> <de...@openoffice.apache.org>
>>>>> >
>>>>>
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**a**pache.org<http://apache.org>
>>> <de...@openoffice.apache.org>
>>> >
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [proposal] Patches on Windows
Posted by Andre Fischer <aw...@gmail.com>.
On 22.10.2013 13:32, janI wrote:
> On 22 October 2013 13:10, Andre Fischer <aw...@gmail.com> wrote:
>
>> On 22.10.2013 12:20, janI wrote:
>>
>>> On 22 October 2013 11:48, Andre Fischer <aw...@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.
There are two parts to this: setup.exe and the included msi. Adding
support to the msi might be easier than we think. At least the 'File'
table has a 'Language' column. I think the table that contains the UI
messages that are displayed during the installation has something
similar. If this column acts as a filter then all we have to do is add
entries for all languages and let the msi select the right ones
automatically. The setup.exe is build by the NSIS installer creator. I
don't know if and how it supports multiple languages.
>
>> - 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.
Yes, but how do we decide which of the many spell checkers to install?
All of them all the time? Or only a subset, depending on the locale?
>
> Why do you see this as a disadvantage to our users.
I only see the larger download as disadvantage. I don't know how many
people really would want to have even more spell checkers installed on
their system and would accept an increase of 1/3 of our already large
installation sets.
The main reason for using patches instead of full installation sets is
their reduced size. Including all available languages might reduce that
advantage.
-Andre
>
> 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>
>>>> <de...@openoffice.apache.org>
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by janI <ja...@apache.org>.
On 22 October 2013 13:10, Andre Fischer <aw...@gmail.com> wrote:
> On 22.10.2013 12:20, janI wrote:
>
>> On 22 October 2013 11:48, Andre Fischer <aw...@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>
>>> <de...@openoffice.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [proposal] Patches on Windows
Posted by Andre Fischer <aw...@gmail.com>.
On 22.10.2013 12:20, janI wrote:
> On 22 October 2013 11:48, Andre Fischer <aw...@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
- UI language of OpenOffice
- Languages supported by spell checker et al.
>
> 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
'$scpactionsinproductlanguageresolvedarrayref'. 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/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_**
>> 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>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [proposal] Patches on Windows
Posted by janI <ja...@apache.org>.
On 22 October 2013 11:48, Andre Fischer <aw...@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.
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.
>
>
> 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_**
> 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>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>