You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Jürgen Schmidt <jo...@gmail.com> on 2013/05/27 17:17:32 UTC
[RELEASE]: proposed further schedule towards AOO 4.0
Hi,
I would like to discuss our further schedule towards AOO 4.0 and the
problems I see. And I would like to discuss a proposal how to address
these problems.
We are behind our schedule a little bit and we have identified some
problems regarding the 64bit port on MacOS that I will try to explain
below (hopefully without too many technical details that everybody can
understand it).
Proposal
========
- Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
(all platforms) asap into trunk and include them in AOO 4.0.
- Move into showstopper mode next week, beginning with June 3th. Means
we integrate only showstopper flagged issues and new translations. And
potentially new art work if we get a new logo and icons in time.
Deadline for new art work should be June 10th.
- Intensive QA with the stlport changes to detect potential problems
- Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
have integrated already returned translations.
- Translation deadline will be set to June 14th to have some time for
the integration and further testing. Further translations can we release
at a later time as a special language update release (TBD)
I would still like to keep the end of June date because everything else
looks quite nice and we should give our users the new sidebar.
A shifted release date won't really help us because we will move in the
vacation time and I think it is better to bring the 4.0 version out before.
Once we have solved the mozilla problem for the 64bit version we can
decide if we want release a 4.1 immediately or later together with
further improvements, fixes and further languages.
Background Explanation
======================
Herbert did a great job with his ongoing work to port AOO to 64bit on
the MacOS platform. This work is mainly triggered and motivated by the
deprecation of some system abi's and the drop of 32 bit Java. In short
we switched to the clang compiler, a new platform SDK, XCode4, replaced
for example atsui API with CoreText, get rid of stlport (on all
platforms) and did many more cleanup that work that were necessary
because of better and/or different compiler/linker behaviour or error
messages etc. Everything looked quite well until we focused on the still
used precompiled older Mozilla libraries. We currently struggle with
porting this stuff to 64 bit and evaluating if we can get rid of them
completely. A complete drop of the mozilla libs would be a further huge
improvement but it is of course a lot of work to understand the code
first and all dependencies and to replace it with some new code... At
the moment we see this on risk for AOO 4.0 and plan to postpone this to 4.1.
But the drop of the stlport lib is relevant for all platforms and will
introduce a binary incompatibility. The best and only time for such an
incompatible change is a major version. The plan is to extract the
stlport relevant changes and merge them on trunk asap (this week). This
will decouple any further work on the 64bit port and we can release the
64bit version at any time later (as 4.1) because the 64bit version is
based on a completely new platform on MacOS additionally to the existing
one.
The 32bit version will be part of the AOO 4.0 release and we will need
this version for backward compatibility on older system anyway. The
64bit version will run on 10.7 and newer only.
I am looking forward to any constructive feedback or concerns.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Montag, 27. Mai 2013 um 18:58 schrieb janI:
> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
>
> > Hi,
> >
> > I would like to discuss our further schedule towards AOO 4.0 and the
> > problems I see. And I would like to discuss a proposal how to address
> > these problems.
> >
> > We are behind our schedule a little bit and we have identified some
> > problems regarding the 64bit port on MacOS that I will try to explain
> > below (hopefully without too many technical details that everybody can
> > understand it).
> >
> > Proposal
> > ========
> > - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> > (all platforms) asap into trunk and include them in AOO 4.0.
> >
> > - Move into showstopper mode next week, beginning with June 3th. Means
> > we integrate only showstopper flagged issues and new translations. And
> > potentially new art work if we get a new logo and icons in time.
> > Deadline for new art work should be June 10th.
> >
> > I understand your motivation and will not be the showstopper. but my
> honest opion is that the reasons for calling it 4.0 get very thin.
>
>
it's ok to have different opinions but let me explain why I think it's worth a new major version. The sidebar in the form we introduce with the next release is a big UI change, very visible to our users. This kind of changes should be made for major releases only.
>
> Getting a 64 bit release for mac (and possible in linux) is something (as
> you write) for a major version and not a minor version like 4.1.
>
>
Ariel pointed already out that Linux is not relevant here and we support a 64bit version already. As I tried to explain a 64bit version on MacOS is comparable to a new platform, a complete new port and that is possible to every version.
>
> I am against (but will vote -0) of making a release just to hold the
> deadline, I would very much prefer to see what a realistic deadline would
> be.
>
>
It is not only to hold a deadline, it is of course time for a new release and we have a lot good stuff in it. How long do we want to move if we would move at all? 2 weeks, 4 weeks or 2 month? What would it change during the summer and vacation time? I believe not really much and we would potentially have only some further bug fixes and maybe the 64bit MacOS version.
I prefer of course to give our users the new sidebar as soon as possible and receive feedback to make this feature even more shining in a 4.1.
Juergen
>
> rgds
> jan I.
>
> Ps. You do a great job as release manager, but someone has to be "devils
> advocate".
>
>
> > - Intensive QA with the stlport changes to detect potential problems
> >
> > - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> > have integrated already returned translations.
> >
> > - Translation deadline will be set to June 14th to have some time for
> > the integration and further testing. Further translations can we release
> > at a later time as a special language update release (TBD)
> >
> >
> >
> > I would still like to keep the end of June date because everything else
> > looks quite nice and we should give our users the new sidebar.
> >
> > A shifted release date won't really help us because we will move in the
> > vacation time and I think it is better to bring the 4.0 version out before.
> >
> > Once we have solved the mozilla problem for the 64bit version we can
> > decide if we want release a 4.1 immediately or later together with
> > further improvements, fixes and further languages.
> >
> >
> > Background Explanation
> > ======================
> >
> > Herbert did a great job with his ongoing work to port AOO to 64bit on
> > the MacOS platform. This work is mainly triggered and motivated by the
> > deprecation of some system abi's and the drop of 32 bit Java. In short
> > we switched to the clang compiler, a new platform SDK, XCode4, replaced
> > for example atsui API with CoreText, get rid of stlport (on all
> > platforms) and did many more cleanup that work that were necessary
> > because of better and/or different compiler/linker behaviour or error
> > messages etc. Everything looked quite well until we focused on the still
> > used precompiled older Mozilla libraries. We currently struggle with
> > porting this stuff to 64 bit and evaluating if we can get rid of them
> > completely. A complete drop of the mozilla libs would be a further huge
> > improvement but it is of course a lot of work to understand the code
> > first and all dependencies and to replace it with some new code... At
> > the moment we see this on risk for AOO 4.0 and plan to postpone this to
> > 4.1.
> >
> > But the drop of the stlport lib is relevant for all platforms and will
> > introduce a binary incompatibility. The best and only time for such an
> > incompatible change is a major version. The plan is to extract the
> > stlport relevant changes and merge them on trunk asap (this week). This
> > will decouple any further work on the 64bit port and we can release the
> > 64bit version at any time later (as 4.1) because the 64bit version is
> > based on a completely new platform on MacOS additionally to the existing
> > one.
> >
> > The 32bit version will be part of the AOO 4.0 release and we will need
> > this version for backward compatibility on older system anyway. The
> > 64bit version will run on 10.7 and newer only.
> >
> >
> > I am looking forward to any constructive feedback or concerns.
> >
> > Juergen
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
>
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Dave Fisher <da...@comcast.net>.
On May 27, 2013, at 2:46 PM, Rob Weir wrote:
> On Mon, May 27, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
>> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to discuss our further schedule towards AOO 4.0 and the
>>> problems I see. And I would like to discuss a proposal how to address
>>> these problems.
>>>
>>> We are behind our schedule a little bit and we have identified some
>>> problems regarding the 64bit port on MacOS that I will try to explain
>>> below (hopefully without too many technical details that everybody can
>>> understand it).
>>>
>>> Proposal
>>> ========
>>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
>>> (all platforms) asap into trunk and include them in AOO 4.0.
>>>
>>> - Move into showstopper mode next week, beginning with June 3th. Means
>>> we integrate only showstopper flagged issues and new translations. And
>>> potentially new art work if we get a new logo and icons in time.
>>> Deadline for new art work should be June 10th.
>>>
>>> I understand your motivation and will not be the showstopper. but my
>> honest opion is that the reasons for calling it 4.0 get very thin.
>>
>
> You might want to put your negative quotes into their own threads to
> make it easier for those opposed to the project to find it and put it
> into Wikipedia or an article.
>
>> Getting a 64 bit release for mac (and possible in linux) is something (as
>> you write) for a major version and not a minor version like 4.1.
>>
>
> We already have Linux 64 bit.
>
>> I am against (but will vote -0) of making a release just to hold the
>> deadline, I would very much prefer to see what a realistic deadline would
>> be.
>>
>
> Fortunately publishing a release at Apache requires only three +1 PMC
> votes and there are no vetos. The process is biased toward making it
> easy to release.
The main process is mechanical. My check list:
(1) Is the packaging complete?
(2) Are the signatures and checksums on the packages correct?
(3) Is the signature that of the Release Manager?
(4) Are the LICENSE and NOTICE file included and correct?
(5) Does the source release match a checkout of the release tag from svn?
(6) Is the RAT report on the source package clean? If not, are only a few files incorrect?
If any of the above is a definitive "NO" then I am "-1" for good technical reasons.
An answer of "NO" to (6) becomes a judgement call on the meaning of "few".
If all are "YES" then I am "+1".
Following the above protects our users by assuring that the IP is properly licensed and that released packages can be authenticated by them.
(Leaving out the fact that this authentication is hard and non-standard. Leaving out any discussion about digital signatures.)
Given the large number of packages in our releases I would like to discuss how we can automate performing our checks. A good starting point would be configuration that is used to support the download page.
Regards,
Dave
>
> -Rob
>
>> rgds
>> jan I.
>>
>> Ps. You do a great job as release manager, but someone has to be "devils
>> advocate".
>>
>>
>>> - Intensive QA with the stlport changes to detect potential problems
>>>
>>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
>>> have integrated already returned translations.
>>>
>>> - Translation deadline will be set to June 14th to have some time for
>>> the integration and further testing. Further translations can we release
>>> at a later time as a special language update release (TBD)
>>>
>>>
>>>
>>> I would still like to keep the end of June date because everything else
>>> looks quite nice and we should give our users the new sidebar.
>>>
>>> A shifted release date won't really help us because we will move in the
>>> vacation time and I think it is better to bring the 4.0 version out before.
>>>
>>> Once we have solved the mozilla problem for the 64bit version we can
>>> decide if we want release a 4.1 immediately or later together with
>>> further improvements, fixes and further languages.
>>>
>>>
>>> Background Explanation
>>> ======================
>>>
>>> Herbert did a great job with his ongoing work to port AOO to 64bit on
>>> the MacOS platform. This work is mainly triggered and motivated by the
>>> deprecation of some system abi's and the drop of 32 bit Java. In short
>>> we switched to the clang compiler, a new platform SDK, XCode4, replaced
>>> for example atsui API with CoreText, get rid of stlport (on all
>>> platforms) and did many more cleanup that work that were necessary
>>> because of better and/or different compiler/linker behaviour or error
>>> messages etc. Everything looked quite well until we focused on the still
>>> used precompiled older Mozilla libraries. We currently struggle with
>>> porting this stuff to 64 bit and evaluating if we can get rid of them
>>> completely. A complete drop of the mozilla libs would be a further huge
>>> improvement but it is of course a lot of work to understand the code
>>> first and all dependencies and to replace it with some new code... At
>>> the moment we see this on risk for AOO 4.0 and plan to postpone this to
>>> 4.1.
>>>
>>> But the drop of the stlport lib is relevant for all platforms and will
>>> introduce a binary incompatibility. The best and only time for such an
>>> incompatible change is a major version. The plan is to extract the
>>> stlport relevant changes and merge them on trunk asap (this week). This
>>> will decouple any further work on the 64bit port and we can release the
>>> 64bit version at any time later (as 4.1) because the 64bit version is
>>> based on a completely new platform on MacOS additionally to the existing
>>> one.
>>>
>>> The 32bit version will be part of the AOO 4.0 release and we will need
>>> this version for backward compatibility on older system anyway. The
>>> 64bit version will run on 10.7 and newer only.
>>>
>>>
>>> I am looking forward to any constructive feedback or concerns.
>>>
>>> Juergen
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Rory O'Farrell <of...@iol.ie>.
On Tue, 28 May 2013 13:57:42 +0200
Jürgen Schmidt <jo...@gmail.com> wrote:
> On 5/28/13 1:03 PM, janI wrote:
> > On 28 May 2013 09:38, Jürgen Schmidt <jo...@gmail.com> wrote:
> >
> >> On 5/27/13 11:46 PM, Rob Weir wrote:
> >>> On Mon, May 27, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
> >>>> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I would like to discuss our further schedule towards AOO 4.0 and the
> >>>>> problems I see. And I would like to discuss a proposal how to address
> >>>>> these problems.
> >>>>>
> >>>>> We are behind our schedule a little bit and we have identified some
> >>>>> problems regarding the 64bit port on MacOS that I will try to explain
> >>>>> below (hopefully without too many technical details that everybody can
> >>>>> understand it).
> >>>>>
> >>>>> Proposal
> >>>>> ========
> >>>>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> >>>>> (all platforms) asap into trunk and include them in AOO 4.0.
> >>>>>
> >>>>> - Move into showstopper mode next week, beginning with June 3th. Means
> >>>>> we integrate only showstopper flagged issues and new translations. And
> >>>>> potentially new art work if we get a new logo and icons in time.
> >>>>> Deadline for new art work should be June 10th.
> >>>>>
> >>>>> I understand your motivation and will not be the showstopper. but my
> >>>> honest opion is that the reasons for calling it 4.0 get very thin.
> >>>>
> >>>
> >>> You might want to put your negative quotes into their own threads to
> >>> make it easier for those opposed to the project to find it and put it
> >>> into Wikipedia or an article.
> >>
> >> both comments from you both doesn't help us in any way to move forward
> >> with our release or address the topic that I tired to discuss.
> >>
> >> For the record I am NOT opposed to the project, if I were I would not do
> > that much work for the project.
>
> We know and we appreciate what you are doing.
>
> The point is that we are not in a perfect world and here in our project
> it's the same. We have to live and work with certain circumstances and
> have to make the best out of it.
>
> The key question is what is the best solution to move forward and don't
> postpone our release to long. I really would like to have a release with
> the sidebar before LO. Well it's not critical but I would prefer if
> possible. They have already integrated the sidebar in their 4.1 branch
> as experimental feature. It will be interesting to see how they
> communicate this feature.
>
> Juergen
>
>
> >
> > Juergen, you are quite right, please go ahead as do as you think are best
> > to get the release out as soon as possible.
> >
> > rgds
> > jan I.
> >
> >
> >>>
> >>>> Getting a 64 bit release for mac (and possible in linux) is something
> >> (as
> >>>> you write) for a major version and not a minor version like 4.1.
> >>>>
> >>>
> >>> We already have Linux 64 bit.
> >>>
> >>>> I am against (but will vote -0) of making a release just to hold the
> >>>> deadline, I would very much prefer to see what a realistic deadline
> >> would
> >>>> be.
> >>>>
> >>>
> >>> Fortunately publishing a release at Apache requires only three +1 PMC
> >>> votes and there are no vetos. The process is biased toward making it
> >>> easy to release.
> >>
> >> we need no discussion in this thread about the proceeding how we do
> >> releases here at Apache. We already did it twice and if people want to
> >> discuss it please in a new thread.
> >>
> >> In this thread I would like to discuss the technical issues around my
> >> proposal and the impact on our release oo how we want to move forward.
> >>
> >> Juergen
> >>
> >>>
> >>> -Rob
> >>>
> >>>> rgds
> >>>> jan I.
> >>>>
> >>>> Ps. You do a great job as release manager, but someone has to be "devils
> >>>> advocate".
> >>>>
> >>>>
> >>>>> - Intensive QA with the stlport changes to detect potential problems
> >>>>>
> >>>>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> >>>>> have integrated already returned translations.
> >>>>>
> >>>>> - Translation deadline will be set to June 14th to have some time for
> >>>>> the integration and further testing. Further translations can we
> >> release
> >>>>> at a later time as a special language update release (TBD)
> >>>>>
> >>>>>
> >>>>>
> >>>>> I would still like to keep the end of June date because everything else
> >>>>> looks quite nice and we should give our users the new sidebar.
> >>>>>
> >>>>> A shifted release date won't really help us because we will move in the
> >>>>> vacation time and I think it is better to bring the 4.0 version out
> >> before.
> >>>>>
> >>>>> Once we have solved the mozilla problem for the 64bit version we can
> >>>>> decide if we want release a 4.1 immediately or later together with
> >>>>> further improvements, fixes and further languages.
> >>>>>
> >>>>>
> >>>>> Background Explanation
> >>>>> ======================
> >>>>>
> >>>>> Herbert did a great job with his ongoing work to port AOO to 64bit on
> >>>>> the MacOS platform. This work is mainly triggered and motivated by the
> >>>>> deprecation of some system abi's and the drop of 32 bit Java. In short
> >>>>> we switched to the clang compiler, a new platform SDK, XCode4, replaced
> >>>>> for example atsui API with CoreText, get rid of stlport (on all
> >>>>> platforms) and did many more cleanup that work that were necessary
> >>>>> because of better and/or different compiler/linker behaviour or error
> >>>>> messages etc. Everything looked quite well until we focused on the
> >> still
> >>>>> used precompiled older Mozilla libraries. We currently struggle with
> >>>>> porting this stuff to 64 bit and evaluating if we can get rid of them
> >>>>> completely. A complete drop of the mozilla libs would be a further huge
> >>>>> improvement but it is of course a lot of work to understand the code
> >>>>> first and all dependencies and to replace it with some new code... At
> >>>>> the moment we see this on risk for AOO 4.0 and plan to postpone this to
> >>>>> 4.1.
> >>>>>
> >>>>> But the drop of the stlport lib is relevant for all platforms and will
> >>>>> introduce a binary incompatibility. The best and only time for such an
> >>>>> incompatible change is a major version. The plan is to extract the
> >>>>> stlport relevant changes and merge them on trunk asap (this week). This
> >>>>> will decouple any further work on the 64bit port and we can release the
> >>>>> 64bit version at any time later (as 4.1) because the 64bit version is
> >>>>> based on a completely new platform on MacOS additionally to the
> >> existing
> >>>>> one.
> >>>>>
> >>>>> The 32bit version will be part of the AOO 4.0 release and we will need
> >>>>> this version for backward compatibility on older system anyway. The
> >>>>> 64bit version will run on 10.7 and newer only.
> >>>>>
> >>>>>
> >>>>> I am looking forward to any constructive feedback or concerns.
> >>>>>
> >>>>> Juergen
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> 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
> >>
> >>
I suggest that AOO 4.0 should be released as soon as practicable; if some major section (Mac 64?) is not ready, then the release of the main body of work should not be delayed to await such a section. The non-release of any delayed section can be noted and promised for RSN (Real Soon Now, if anyone remembers early CP/M days) and released as and when ready, without being held for AOO 4.1
To miss the intended date will leave the AOO project open to derogatory comments.
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 5/28/13 1:03 PM, janI wrote:
> On 28 May 2013 09:38, Jürgen Schmidt <jo...@gmail.com> wrote:
>
>> On 5/27/13 11:46 PM, Rob Weir wrote:
>>> On Mon, May 27, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
>>>> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I would like to discuss our further schedule towards AOO 4.0 and the
>>>>> problems I see. And I would like to discuss a proposal how to address
>>>>> these problems.
>>>>>
>>>>> We are behind our schedule a little bit and we have identified some
>>>>> problems regarding the 64bit port on MacOS that I will try to explain
>>>>> below (hopefully without too many technical details that everybody can
>>>>> understand it).
>>>>>
>>>>> Proposal
>>>>> ========
>>>>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
>>>>> (all platforms) asap into trunk and include them in AOO 4.0.
>>>>>
>>>>> - Move into showstopper mode next week, beginning with June 3th. Means
>>>>> we integrate only showstopper flagged issues and new translations. And
>>>>> potentially new art work if we get a new logo and icons in time.
>>>>> Deadline for new art work should be June 10th.
>>>>>
>>>>> I understand your motivation and will not be the showstopper. but my
>>>> honest opion is that the reasons for calling it 4.0 get very thin.
>>>>
>>>
>>> You might want to put your negative quotes into their own threads to
>>> make it easier for those opposed to the project to find it and put it
>>> into Wikipedia or an article.
>>
>> both comments from you both doesn't help us in any way to move forward
>> with our release or address the topic that I tired to discuss.
>>
>> For the record I am NOT opposed to the project, if I were I would not do
> that much work for the project.
We know and we appreciate what you are doing.
The point is that we are not in a perfect world and here in our project
it's the same. We have to live and work with certain circumstances and
have to make the best out of it.
The key question is what is the best solution to move forward and don't
postpone our release to long. I really would like to have a release with
the sidebar before LO. Well it's not critical but I would prefer if
possible. They have already integrated the sidebar in their 4.1 branch
as experimental feature. It will be interesting to see how they
communicate this feature.
Juergen
>
> Juergen, you are quite right, please go ahead as do as you think are best
> to get the release out as soon as possible.
>
> rgds
> jan I.
>
>
>>>
>>>> Getting a 64 bit release for mac (and possible in linux) is something
>> (as
>>>> you write) for a major version and not a minor version like 4.1.
>>>>
>>>
>>> We already have Linux 64 bit.
>>>
>>>> I am against (but will vote -0) of making a release just to hold the
>>>> deadline, I would very much prefer to see what a realistic deadline
>> would
>>>> be.
>>>>
>>>
>>> Fortunately publishing a release at Apache requires only three +1 PMC
>>> votes and there are no vetos. The process is biased toward making it
>>> easy to release.
>>
>> we need no discussion in this thread about the proceeding how we do
>> releases here at Apache. We already did it twice and if people want to
>> discuss it please in a new thread.
>>
>> In this thread I would like to discuss the technical issues around my
>> proposal and the impact on our release oo how we want to move forward.
>>
>> Juergen
>>
>>>
>>> -Rob
>>>
>>>> rgds
>>>> jan I.
>>>>
>>>> Ps. You do a great job as release manager, but someone has to be "devils
>>>> advocate".
>>>>
>>>>
>>>>> - Intensive QA with the stlport changes to detect potential problems
>>>>>
>>>>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
>>>>> have integrated already returned translations.
>>>>>
>>>>> - Translation deadline will be set to June 14th to have some time for
>>>>> the integration and further testing. Further translations can we
>> release
>>>>> at a later time as a special language update release (TBD)
>>>>>
>>>>>
>>>>>
>>>>> I would still like to keep the end of June date because everything else
>>>>> looks quite nice and we should give our users the new sidebar.
>>>>>
>>>>> A shifted release date won't really help us because we will move in the
>>>>> vacation time and I think it is better to bring the 4.0 version out
>> before.
>>>>>
>>>>> Once we have solved the mozilla problem for the 64bit version we can
>>>>> decide if we want release a 4.1 immediately or later together with
>>>>> further improvements, fixes and further languages.
>>>>>
>>>>>
>>>>> Background Explanation
>>>>> ======================
>>>>>
>>>>> Herbert did a great job with his ongoing work to port AOO to 64bit on
>>>>> the MacOS platform. This work is mainly triggered and motivated by the
>>>>> deprecation of some system abi's and the drop of 32 bit Java. In short
>>>>> we switched to the clang compiler, a new platform SDK, XCode4, replaced
>>>>> for example atsui API with CoreText, get rid of stlport (on all
>>>>> platforms) and did many more cleanup that work that were necessary
>>>>> because of better and/or different compiler/linker behaviour or error
>>>>> messages etc. Everything looked quite well until we focused on the
>> still
>>>>> used precompiled older Mozilla libraries. We currently struggle with
>>>>> porting this stuff to 64 bit and evaluating if we can get rid of them
>>>>> completely. A complete drop of the mozilla libs would be a further huge
>>>>> improvement but it is of course a lot of work to understand the code
>>>>> first and all dependencies and to replace it with some new code... At
>>>>> the moment we see this on risk for AOO 4.0 and plan to postpone this to
>>>>> 4.1.
>>>>>
>>>>> But the drop of the stlport lib is relevant for all platforms and will
>>>>> introduce a binary incompatibility. The best and only time for such an
>>>>> incompatible change is a major version. The plan is to extract the
>>>>> stlport relevant changes and merge them on trunk asap (this week). This
>>>>> will decouple any further work on the 64bit port and we can release the
>>>>> 64bit version at any time later (as 4.1) because the 64bit version is
>>>>> based on a completely new platform on MacOS additionally to the
>> existing
>>>>> one.
>>>>>
>>>>> The 32bit version will be part of the AOO 4.0 release and we will need
>>>>> this version for backward compatibility on older system anyway. The
>>>>> 64bit version will run on 10.7 and newer only.
>>>>>
>>>>>
>>>>> I am looking forward to any constructive feedback or concerns.
>>>>>
>>>>> Juergen
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by janI <ja...@apache.org>.
On 28 May 2013 09:38, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 5/27/13 11:46 PM, Rob Weir wrote:
> > On Mon, May 27, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
> >> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> I would like to discuss our further schedule towards AOO 4.0 and the
> >>> problems I see. And I would like to discuss a proposal how to address
> >>> these problems.
> >>>
> >>> We are behind our schedule a little bit and we have identified some
> >>> problems regarding the 64bit port on MacOS that I will try to explain
> >>> below (hopefully without too many technical details that everybody can
> >>> understand it).
> >>>
> >>> Proposal
> >>> ========
> >>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> >>> (all platforms) asap into trunk and include them in AOO 4.0.
> >>>
> >>> - Move into showstopper mode next week, beginning with June 3th. Means
> >>> we integrate only showstopper flagged issues and new translations. And
> >>> potentially new art work if we get a new logo and icons in time.
> >>> Deadline for new art work should be June 10th.
> >>>
> >>> I understand your motivation and will not be the showstopper. but my
> >> honest opion is that the reasons for calling it 4.0 get very thin.
> >>
> >
> > You might want to put your negative quotes into their own threads to
> > make it easier for those opposed to the project to find it and put it
> > into Wikipedia or an article.
>
> both comments from you both doesn't help us in any way to move forward
> with our release or address the topic that I tired to discuss.
>
> For the record I am NOT opposed to the project, if I were I would not do
that much work for the project.
Juergen, you are quite right, please go ahead as do as you think are best
to get the release out as soon as possible.
rgds
jan I.
> >
> >> Getting a 64 bit release for mac (and possible in linux) is something
> (as
> >> you write) for a major version and not a minor version like 4.1.
> >>
> >
> > We already have Linux 64 bit.
> >
> >> I am against (but will vote -0) of making a release just to hold the
> >> deadline, I would very much prefer to see what a realistic deadline
> would
> >> be.
> >>
> >
> > Fortunately publishing a release at Apache requires only three +1 PMC
> > votes and there are no vetos. The process is biased toward making it
> > easy to release.
>
> we need no discussion in this thread about the proceeding how we do
> releases here at Apache. We already did it twice and if people want to
> discuss it please in a new thread.
>
> In this thread I would like to discuss the technical issues around my
> proposal and the impact on our release oo how we want to move forward.
>
> Juergen
>
> >
> > -Rob
> >
> >> rgds
> >> jan I.
> >>
> >> Ps. You do a great job as release manager, but someone has to be "devils
> >> advocate".
> >>
> >>
> >>> - Intensive QA with the stlport changes to detect potential problems
> >>>
> >>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> >>> have integrated already returned translations.
> >>>
> >>> - Translation deadline will be set to June 14th to have some time for
> >>> the integration and further testing. Further translations can we
> release
> >>> at a later time as a special language update release (TBD)
> >>>
> >>>
> >>>
> >>> I would still like to keep the end of June date because everything else
> >>> looks quite nice and we should give our users the new sidebar.
> >>>
> >>> A shifted release date won't really help us because we will move in the
> >>> vacation time and I think it is better to bring the 4.0 version out
> before.
> >>>
> >>> Once we have solved the mozilla problem for the 64bit version we can
> >>> decide if we want release a 4.1 immediately or later together with
> >>> further improvements, fixes and further languages.
> >>>
> >>>
> >>> Background Explanation
> >>> ======================
> >>>
> >>> Herbert did a great job with his ongoing work to port AOO to 64bit on
> >>> the MacOS platform. This work is mainly triggered and motivated by the
> >>> deprecation of some system abi's and the drop of 32 bit Java. In short
> >>> we switched to the clang compiler, a new platform SDK, XCode4, replaced
> >>> for example atsui API with CoreText, get rid of stlport (on all
> >>> platforms) and did many more cleanup that work that were necessary
> >>> because of better and/or different compiler/linker behaviour or error
> >>> messages etc. Everything looked quite well until we focused on the
> still
> >>> used precompiled older Mozilla libraries. We currently struggle with
> >>> porting this stuff to 64 bit and evaluating if we can get rid of them
> >>> completely. A complete drop of the mozilla libs would be a further huge
> >>> improvement but it is of course a lot of work to understand the code
> >>> first and all dependencies and to replace it with some new code... At
> >>> the moment we see this on risk for AOO 4.0 and plan to postpone this to
> >>> 4.1.
> >>>
> >>> But the drop of the stlport lib is relevant for all platforms and will
> >>> introduce a binary incompatibility. The best and only time for such an
> >>> incompatible change is a major version. The plan is to extract the
> >>> stlport relevant changes and merge them on trunk asap (this week). This
> >>> will decouple any further work on the 64bit port and we can release the
> >>> 64bit version at any time later (as 4.1) because the 64bit version is
> >>> based on a completely new platform on MacOS additionally to the
> existing
> >>> one.
> >>>
> >>> The 32bit version will be part of the AOO 4.0 release and we will need
> >>> this version for backward compatibility on older system anyway. The
> >>> 64bit version will run on 10.7 and newer only.
> >>>
> >>>
> >>> I am looking forward to any constructive feedback or concerns.
> >>>
> >>> Juergen
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 5/27/13 11:46 PM, Rob Weir wrote:
> On Mon, May 27, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
>> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to discuss our further schedule towards AOO 4.0 and the
>>> problems I see. And I would like to discuss a proposal how to address
>>> these problems.
>>>
>>> We are behind our schedule a little bit and we have identified some
>>> problems regarding the 64bit port on MacOS that I will try to explain
>>> below (hopefully without too many technical details that everybody can
>>> understand it).
>>>
>>> Proposal
>>> ========
>>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
>>> (all platforms) asap into trunk and include them in AOO 4.0.
>>>
>>> - Move into showstopper mode next week, beginning with June 3th. Means
>>> we integrate only showstopper flagged issues and new translations. And
>>> potentially new art work if we get a new logo and icons in time.
>>> Deadline for new art work should be June 10th.
>>>
>>> I understand your motivation and will not be the showstopper. but my
>> honest opion is that the reasons for calling it 4.0 get very thin.
>>
>
> You might want to put your negative quotes into their own threads to
> make it easier for those opposed to the project to find it and put it
> into Wikipedia or an article.
both comments from you both doesn't help us in any way to move forward
with our release or address the topic that I tired to discuss.
>
>> Getting a 64 bit release for mac (and possible in linux) is something (as
>> you write) for a major version and not a minor version like 4.1.
>>
>
> We already have Linux 64 bit.
>
>> I am against (but will vote -0) of making a release just to hold the
>> deadline, I would very much prefer to see what a realistic deadline would
>> be.
>>
>
> Fortunately publishing a release at Apache requires only three +1 PMC
> votes and there are no vetos. The process is biased toward making it
> easy to release.
we need no discussion in this thread about the proceeding how we do
releases here at Apache. We already did it twice and if people want to
discuss it please in a new thread.
In this thread I would like to discuss the technical issues around my
proposal and the impact on our release oo how we want to move forward.
Juergen
>
> -Rob
>
>> rgds
>> jan I.
>>
>> Ps. You do a great job as release manager, but someone has to be "devils
>> advocate".
>>
>>
>>> - Intensive QA with the stlport changes to detect potential problems
>>>
>>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
>>> have integrated already returned translations.
>>>
>>> - Translation deadline will be set to June 14th to have some time for
>>> the integration and further testing. Further translations can we release
>>> at a later time as a special language update release (TBD)
>>>
>>>
>>>
>>> I would still like to keep the end of June date because everything else
>>> looks quite nice and we should give our users the new sidebar.
>>>
>>> A shifted release date won't really help us because we will move in the
>>> vacation time and I think it is better to bring the 4.0 version out before.
>>>
>>> Once we have solved the mozilla problem for the 64bit version we can
>>> decide if we want release a 4.1 immediately or later together with
>>> further improvements, fixes and further languages.
>>>
>>>
>>> Background Explanation
>>> ======================
>>>
>>> Herbert did a great job with his ongoing work to port AOO to 64bit on
>>> the MacOS platform. This work is mainly triggered and motivated by the
>>> deprecation of some system abi's and the drop of 32 bit Java. In short
>>> we switched to the clang compiler, a new platform SDK, XCode4, replaced
>>> for example atsui API with CoreText, get rid of stlport (on all
>>> platforms) and did many more cleanup that work that were necessary
>>> because of better and/or different compiler/linker behaviour or error
>>> messages etc. Everything looked quite well until we focused on the still
>>> used precompiled older Mozilla libraries. We currently struggle with
>>> porting this stuff to 64 bit and evaluating if we can get rid of them
>>> completely. A complete drop of the mozilla libs would be a further huge
>>> improvement but it is of course a lot of work to understand the code
>>> first and all dependencies and to replace it with some new code... At
>>> the moment we see this on risk for AOO 4.0 and plan to postpone this to
>>> 4.1.
>>>
>>> But the drop of the stlport lib is relevant for all platforms and will
>>> introduce a binary incompatibility. The best and only time for such an
>>> incompatible change is a major version. The plan is to extract the
>>> stlport relevant changes and merge them on trunk asap (this week). This
>>> will decouple any further work on the 64bit port and we can release the
>>> 64bit version at any time later (as 4.1) because the 64bit version is
>>> based on a completely new platform on MacOS additionally to the existing
>>> one.
>>>
>>> The 32bit version will be part of the AOO 4.0 release and we will need
>>> this version for backward compatibility on older system anyway. The
>>> 64bit version will run on 10.7 and newer only.
>>>
>>>
>>> I am looking forward to any constructive feedback or concerns.
>>>
>>> Juergen
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 27, 2013 at 12:58 PM, janI <ja...@apache.org> wrote:
> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
>
>> Hi,
>>
>> I would like to discuss our further schedule towards AOO 4.0 and the
>> problems I see. And I would like to discuss a proposal how to address
>> these problems.
>>
>> We are behind our schedule a little bit and we have identified some
>> problems regarding the 64bit port on MacOS that I will try to explain
>> below (hopefully without too many technical details that everybody can
>> understand it).
>>
>> Proposal
>> ========
>> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
>> (all platforms) asap into trunk and include them in AOO 4.0.
>>
>> - Move into showstopper mode next week, beginning with June 3th. Means
>> we integrate only showstopper flagged issues and new translations. And
>> potentially new art work if we get a new logo and icons in time.
>> Deadline for new art work should be June 10th.
>>
>> I understand your motivation and will not be the showstopper. but my
> honest opion is that the reasons for calling it 4.0 get very thin.
>
You might want to put your negative quotes into their own threads to
make it easier for those opposed to the project to find it and put it
into Wikipedia or an article.
> Getting a 64 bit release for mac (and possible in linux) is something (as
> you write) for a major version and not a minor version like 4.1.
>
We already have Linux 64 bit.
> I am against (but will vote -0) of making a release just to hold the
> deadline, I would very much prefer to see what a realistic deadline would
> be.
>
Fortunately publishing a release at Apache requires only three +1 PMC
votes and there are no vetos. The process is biased toward making it
easy to release.
-Rob
> rgds
> jan I.
>
> Ps. You do a great job as release manager, but someone has to be "devils
> advocate".
>
>
>> - Intensive QA with the stlport changes to detect potential problems
>>
>> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
>> have integrated already returned translations.
>>
>> - Translation deadline will be set to June 14th to have some time for
>> the integration and further testing. Further translations can we release
>> at a later time as a special language update release (TBD)
>>
>>
>>
>> I would still like to keep the end of June date because everything else
>> looks quite nice and we should give our users the new sidebar.
>>
>> A shifted release date won't really help us because we will move in the
>> vacation time and I think it is better to bring the 4.0 version out before.
>>
>> Once we have solved the mozilla problem for the 64bit version we can
>> decide if we want release a 4.1 immediately or later together with
>> further improvements, fixes and further languages.
>>
>>
>> Background Explanation
>> ======================
>>
>> Herbert did a great job with his ongoing work to port AOO to 64bit on
>> the MacOS platform. This work is mainly triggered and motivated by the
>> deprecation of some system abi's and the drop of 32 bit Java. In short
>> we switched to the clang compiler, a new platform SDK, XCode4, replaced
>> for example atsui API with CoreText, get rid of stlport (on all
>> platforms) and did many more cleanup that work that were necessary
>> because of better and/or different compiler/linker behaviour or error
>> messages etc. Everything looked quite well until we focused on the still
>> used precompiled older Mozilla libraries. We currently struggle with
>> porting this stuff to 64 bit and evaluating if we can get rid of them
>> completely. A complete drop of the mozilla libs would be a further huge
>> improvement but it is of course a lot of work to understand the code
>> first and all dependencies and to replace it with some new code... At
>> the moment we see this on risk for AOO 4.0 and plan to postpone this to
>> 4.1.
>>
>> But the drop of the stlport lib is relevant for all platforms and will
>> introduce a binary incompatibility. The best and only time for such an
>> incompatible change is a major version. The plan is to extract the
>> stlport relevant changes and merge them on trunk asap (this week). This
>> will decouple any further work on the 64bit port and we can release the
>> 64bit version at any time later (as 4.1) because the 64bit version is
>> based on a completely new platform on MacOS additionally to the existing
>> one.
>>
>> The 32bit version will be part of the AOO 4.0 release and we will need
>> this version for backward compatibility on older system anyway. The
>> 64bit version will run on 10.7 and newer only.
>>
>>
>> I am looking forward to any constructive feedback or concerns.
>>
>> Juergen
>>
>>
>> ---------------------------------------------------------------------
>> 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Montag, 27. Mai 2013 um 19:47 schrieb Ariel Constenla-Haile:
> On Mon, May 27, 2013 at 06:58:54PM +0200, janI wrote:
> > On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I would like to discuss our further schedule towards AOO 4.0 and the
> > > problems I see. And I would like to discuss a proposal how to address
> > > these problems.
> > >
> > > We are behind our schedule a little bit and we have identified some
> > > problems regarding the 64bit port on MacOS that I will try to explain
> > > below (hopefully without too many technical details that everybody can
> > > understand it).
> > >
> > > Proposal
> > > ========
> > > - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> > > (all platforms) asap into trunk and include them in AOO 4.0.
> > >
> > > - Move into showstopper mode next week, beginning with June 3th. Means
> > > we integrate only showstopper flagged issues and new translations. And
> > > potentially new art work if we get a new logo and icons in time.
> > > Deadline for new art work should be June 10th.
> > >
> > > I understand your motivation and will not be the showstopper. but my
> > honest opion is that the reasons for calling it 4.0 get very thin.
> >
> > Getting a 64 bit release for mac (and possible in linux)
>
> For Linux we already release a 64 bit version, together with the 32
> bits.
>
> > is something (as you write) for a major version and not a minor
> > version like 4.1.
> >
>
>
> The bitness is not that important, if I understood clearly, it's not
> like we are dropping 32 bit support in MacOS for 4.1. What might be
> something to think about is the change in the system requirements
> between 4.0 and 4.1; we had unintentionally changed the system
> requirements in Linux from previous versions released by Sun/Oracle,
> this turned into some people saying "you better install LO, that works
> on older Linux distros".
>
>
it is not only our decision and we have to react. Apple deprecated API's and we have to make some changes to be ready for the future. We will still support the 32bit version for older versions. But some of the changes Herbert made will be available on newer os versions and with the new platform.
Juergen
>
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
>
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Mon, May 27, 2013 at 06:58:54PM +0200, janI wrote:
> On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
>
> > Hi,
> >
> > I would like to discuss our further schedule towards AOO 4.0 and the
> > problems I see. And I would like to discuss a proposal how to address
> > these problems.
> >
> > We are behind our schedule a little bit and we have identified some
> > problems regarding the 64bit port on MacOS that I will try to explain
> > below (hopefully without too many technical details that everybody can
> > understand it).
> >
> > Proposal
> > ========
> > - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> > (all platforms) asap into trunk and include them in AOO 4.0.
> >
> > - Move into showstopper mode next week, beginning with June 3th. Means
> > we integrate only showstopper flagged issues and new translations. And
> > potentially new art work if we get a new logo and icons in time.
> > Deadline for new art work should be June 10th.
> >
> > I understand your motivation and will not be the showstopper. but my
> honest opion is that the reasons for calling it 4.0 get very thin.
>
> Getting a 64 bit release for mac (and possible in linux)
For Linux we already release a 64 bit version, together with the 32
bits.
> is something (as you write) for a major version and not a minor
> version like 4.1.
The bitness is not that important, if I understood clearly, it's not
like we are dropping 32 bit support in MacOS for 4.1. What might be
something to think about is the change in the system requirements
between 4.0 and 4.1; we had unintentionally changed the system
requirements in Linux from previous versions released by Sun/Oracle,
this turned into some people saying "you better install LO, that works
on older Linux distros".
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by janI <ja...@apache.org>.
On 27 May 2013 17:17, Jürgen Schmidt <jo...@gmail.com> wrote:
> Hi,
>
> I would like to discuss our further schedule towards AOO 4.0 and the
> problems I see. And I would like to discuss a proposal how to address
> these problems.
>
> We are behind our schedule a little bit and we have identified some
> problems regarding the 64bit port on MacOS that I will try to explain
> below (hopefully without too many technical details that everybody can
> understand it).
>
> Proposal
> ========
> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> (all platforms) asap into trunk and include them in AOO 4.0.
>
> - Move into showstopper mode next week, beginning with June 3th. Means
> we integrate only showstopper flagged issues and new translations. And
> potentially new art work if we get a new logo and icons in time.
> Deadline for new art work should be June 10th.
>
> I understand your motivation and will not be the showstopper. but my
honest opion is that the reasons for calling it 4.0 get very thin.
Getting a 64 bit release for mac (and possible in linux) is something (as
you write) for a major version and not a minor version like 4.1.
I am against (but will vote -0) of making a release just to hold the
deadline, I would very much prefer to see what a realistic deadline would
be.
rgds
jan I.
Ps. You do a great job as release manager, but someone has to be "devils
advocate".
> - Intensive QA with the stlport changes to detect potential problems
>
> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> have integrated already returned translations.
>
> - Translation deadline will be set to June 14th to have some time for
> the integration and further testing. Further translations can we release
> at a later time as a special language update release (TBD)
>
>
>
> I would still like to keep the end of June date because everything else
> looks quite nice and we should give our users the new sidebar.
>
> A shifted release date won't really help us because we will move in the
> vacation time and I think it is better to bring the 4.0 version out before.
>
> Once we have solved the mozilla problem for the 64bit version we can
> decide if we want release a 4.1 immediately or later together with
> further improvements, fixes and further languages.
>
>
> Background Explanation
> ======================
>
> Herbert did a great job with his ongoing work to port AOO to 64bit on
> the MacOS platform. This work is mainly triggered and motivated by the
> deprecation of some system abi's and the drop of 32 bit Java. In short
> we switched to the clang compiler, a new platform SDK, XCode4, replaced
> for example atsui API with CoreText, get rid of stlport (on all
> platforms) and did many more cleanup that work that were necessary
> because of better and/or different compiler/linker behaviour or error
> messages etc. Everything looked quite well until we focused on the still
> used precompiled older Mozilla libraries. We currently struggle with
> porting this stuff to 64 bit and evaluating if we can get rid of them
> completely. A complete drop of the mozilla libs would be a further huge
> improvement but it is of course a lot of work to understand the code
> first and all dependencies and to replace it with some new code... At
> the moment we see this on risk for AOO 4.0 and plan to postpone this to
> 4.1.
>
> But the drop of the stlport lib is relevant for all platforms and will
> introduce a binary incompatibility. The best and only time for such an
> incompatible change is a major version. The plan is to extract the
> stlport relevant changes and merge them on trunk asap (this week). This
> will decouple any further work on the 64bit port and we can release the
> 64bit version at any time later (as 4.1) because the 64bit version is
> based on a completely new platform on MacOS additionally to the existing
> one.
>
> The 32bit version will be part of the AOO 4.0 release and we will need
> this version for backward compatibility on older system anyway. The
> 64bit version will run on 10.7 and newer only.
>
>
> I am looking forward to any constructive feedback or concerns.
>
> Juergen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Shenfeng Liu <li...@gmail.com>.
+1 to move forward.
For the next snapshot without stlport, we need to plan testing on all the
platforms (Windows/Redhat/Suse/Ubuntu/Mac). But I agree that acceptance
level testing will be enough.
- Shenfeng (Simon)
2013/5/31 Jürgen Schmidt <jo...@gmail.com>
> On 5/31/13 9:16 AM, Herbert Dürr wrote:
> > [regarding dropping stlport4]
> >
> > The changes to make the codebase ready for native STL support are done.
> > Builds with stlport4 enabled will continue to work as before.
> >
> > I suggest to use the --without-stlport option for all new builds though:
> > Stlport is a great project, but the versions that OOo depended on had
> > been released more than ten years ago. The library improved greatly
> > since then from a feature, performance and standard compliance
> > perspective. And of course many many bugs have been fixed [1]. In their
> > stlport5 version they continue to improve significantly.
> >
> > Platform STLs have been inspired by stlport, improved greatly too and in
> > the C++11 standardization process divergent views have consolidated. We
> > can rely on the platform STLs. I agree that the timing of the suggested
> > switch is not so good but the switch itself is overdue. A major version
> > change is the right time to do this.
> >
> > [1] relevant examples of fixes that got into stlport releases newer than
> > the ones OOo depended on can be seen at e.g.
> >
> http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=etc/ChangeLog;hb=refs/tags/STLport-STLPORT_4_6
> >
> >
> > On 2013/05/28 2:38 PM, Rob Weir wrote:
> >> In theory every fix can cause bugs. But some fixes are more localized
> >> than others. Fixes with localized impact are easier to test.
> >> Widespread fixes are harder to test, because more code is potentially
> >> broken.
> >
> > The switch was rendered possible by many little changes over the last
> > couple of months which got our code base more in line with C++11
> > expectations. Snapshots based on these changes have been and are already
> > extensively tested by our great QA community. The switch itself is just
> > another step in evolving towards a high quality release.
> >
> > Additionally testing has it much easier to find issues introduced by the
> > switch should there be any. E.g. we have many testers and almost a
> > thousand automatic tests. They work on different platforms. They cover a
> > lot of different areas. The risk that a regression in that layer could
> > remain undetected is very low.
> >
> > Automated testing ran its 940 autotests (in BVT, FVT, SVT and PVT) on
> > different operating systems for 32bit and 64bit versions. The
> > cross-correlation between pre- and post-switch builds is the same as the
> > auto-correlation for test reruns: the same tests were successful on both
> > sides, the same tests failed for both sides.
>
> to make clear that this is a very important and useful step forward. We
> have to do something to be able for a compiler switch and be prepared
> for the next steps etc.. Not only on MacOS but also on FreeBSD, the
> clang compiler don't like the old stlport version ;-) To be serious an
> upgrade to stlport 5 for example won't help us really. It is the same to
> switch to a new version or to get rid of this external library
> completely. We prefer the latter one.
>
> The working automated tests (at least same result as before) makes me
> confident that the change is ok.
>
> I propose that we prepare the next snapshot without stlport and will see
> what happened with our testing. If we run into obvious problems with the
> stl we will switch back immediately.
>
> Juergen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 5/31/13 9:16 AM, Herbert Dürr wrote:
> [regarding dropping stlport4]
>
> The changes to make the codebase ready for native STL support are done.
> Builds with stlport4 enabled will continue to work as before.
>
> I suggest to use the --without-stlport option for all new builds though:
> Stlport is a great project, but the versions that OOo depended on had
> been released more than ten years ago. The library improved greatly
> since then from a feature, performance and standard compliance
> perspective. And of course many many bugs have been fixed [1]. In their
> stlport5 version they continue to improve significantly.
>
> Platform STLs have been inspired by stlport, improved greatly too and in
> the C++11 standardization process divergent views have consolidated. We
> can rely on the platform STLs. I agree that the timing of the suggested
> switch is not so good but the switch itself is overdue. A major version
> change is the right time to do this.
>
> [1] relevant examples of fixes that got into stlport releases newer than
> the ones OOo depended on can be seen at e.g.
> http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=etc/ChangeLog;hb=refs/tags/STLport-STLPORT_4_6
>
>
> On 2013/05/28 2:38 PM, Rob Weir wrote:
>> In theory every fix can cause bugs. But some fixes are more localized
>> than others. Fixes with localized impact are easier to test.
>> Widespread fixes are harder to test, because more code is potentially
>> broken.
>
> The switch was rendered possible by many little changes over the last
> couple of months which got our code base more in line with C++11
> expectations. Snapshots based on these changes have been and are already
> extensively tested by our great QA community. The switch itself is just
> another step in evolving towards a high quality release.
>
> Additionally testing has it much easier to find issues introduced by the
> switch should there be any. E.g. we have many testers and almost a
> thousand automatic tests. They work on different platforms. They cover a
> lot of different areas. The risk that a regression in that layer could
> remain undetected is very low.
>
> Automated testing ran its 940 autotests (in BVT, FVT, SVT and PVT) on
> different operating systems for 32bit and 64bit versions. The
> cross-correlation between pre- and post-switch builds is the same as the
> auto-correlation for test reruns: the same tests were successful on both
> sides, the same tests failed for both sides.
to make clear that this is a very important and useful step forward. We
have to do something to be able for a compiler switch and be prepared
for the next steps etc.. Not only on MacOS but also on FreeBSD, the
clang compiler don't like the old stlport version ;-) To be serious an
upgrade to stlport 5 for example won't help us really. It is the same to
switch to a new version or to get rid of this external library
completely. We prefer the latter one.
The working automated tests (at least same result as before) makes me
confident that the change is ok.
I propose that we prepare the next snapshot without stlport and will see
what happened with our testing. If we run into obvious problems with the
stl we will switch back immediately.
Juergen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, May 31, 2013 at 12:04 PM, Rob Weir <ra...@gmail.com> wrote:
> On May 31, 2013, at 3:16 AM, "Herbert Dürr" <hd...@apache.org> wrote:
>
> > [regarding dropping stlport4]
> >
> > The changes to make the codebase ready for native STL support are done.
> Builds with stlport4 enabled will continue to work as before.
> >
> > I suggest to use the --without-stlport option for all new builds though:
> Stlport is a great project, but the versions that OOo depended on had been
> released more than ten years ago. The library improved greatly since then
> from a feature, performance and standard compliance perspective. And of
> course many many bugs have been fixed [1]. In their stlport5 version they
> continue to improve significantly.
> >
> > Platform STLs have been inspired by stlport, improved greatly too and in
> the C++11 standardization process divergent views have consolidated. We can
> rely on the platform STLs. I agree that the timing of the suggested switch
> is not so good but the switch itself is overdue. A major version change is
> the right time to do this.
> >
> > [1] relevant examples of fixes that got into stlport releases newer than
> the ones OOo depended on can be seen at e.g.
> http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=etc/ChangeLog;hb=refs/tags/STLport-STLPORT_4_6
> >
> > On 2013/05/28 2:38 PM, Rob Weir wrote:
> >> In theory every fix can cause bugs. But some fixes are more localized
> >> than others. Fixes with localized impact are easier to test.
> >> Widespread fixes are harder to test, because more code is potentially
> >> broken.
> >
> > The switch was rendered possible by many little changes over the last
> couple of months which got our code base more in line with C++11
> expectations. Snapshots based on these changes have been and are already
> extensively tested by our great QA community. The switch itself is just
> another step in evolving towards a high quality release.
> >
> > Additionally testing has it much easier to find issues introduced by the
> switch should there be any. E.g. we have many testers and almost a thousand
> automatic tests. They work on different platforms. They cover a lot of
> different areas. The risk that a regression in that layer could remain
> undetected is very low.
> >
> > Automated testing ran its 940 autotests (in BVT, FVT, SVT and PVT) on
> different operating systems for 32bit and 64bit versions. The
> cross-correlation between pre- and post-switch builds is the same as the
> auto-correlation for test reruns: the same tests were successful on both
> sides, the same tests failed for both sides.
> >
>
> This is great. Thanks for giving attention to the quality side of this.
>
> A change like this is unlikely to introduce a subtle bug in only one
> place. If it breaks things it should be spectacular. So the fact that
> nothing is seen yet is a good sign.
>
> -Rob
>
Yes, thanks Herbert for all this information. And, I see I should start
thinking about upgrading to GCC 4.8.1 to comply with C++ 11....really
thanks for posting this.
>
>
> > Herbert
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
----------------------------------------------------------------------------------------
MzK
"You can't believe one thing and do another.
What you believe and what you do are the same thing."
-- Leonard Peltier
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Rob Weir <ra...@gmail.com>.
On May 31, 2013, at 3:16 AM, "Herbert Dürr" <hd...@apache.org> wrote:
> [regarding dropping stlport4]
>
> The changes to make the codebase ready for native STL support are done. Builds with stlport4 enabled will continue to work as before.
>
> I suggest to use the --without-stlport option for all new builds though: Stlport is a great project, but the versions that OOo depended on had been released more than ten years ago. The library improved greatly since then from a feature, performance and standard compliance perspective. And of course many many bugs have been fixed [1]. In their stlport5 version they continue to improve significantly.
>
> Platform STLs have been inspired by stlport, improved greatly too and in the C++11 standardization process divergent views have consolidated. We can rely on the platform STLs. I agree that the timing of the suggested switch is not so good but the switch itself is overdue. A major version change is the right time to do this.
>
> [1] relevant examples of fixes that got into stlport releases newer than the ones OOo depended on can be seen at e.g. http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=etc/ChangeLog;hb=refs/tags/STLport-STLPORT_4_6
>
> On 2013/05/28 2:38 PM, Rob Weir wrote:
>> In theory every fix can cause bugs. But some fixes are more localized
>> than others. Fixes with localized impact are easier to test.
>> Widespread fixes are harder to test, because more code is potentially
>> broken.
>
> The switch was rendered possible by many little changes over the last couple of months which got our code base more in line with C++11 expectations. Snapshots based on these changes have been and are already extensively tested by our great QA community. The switch itself is just another step in evolving towards a high quality release.
>
> Additionally testing has it much easier to find issues introduced by the switch should there be any. E.g. we have many testers and almost a thousand automatic tests. They work on different platforms. They cover a lot of different areas. The risk that a regression in that layer could remain undetected is very low.
>
> Automated testing ran its 940 autotests (in BVT, FVT, SVT and PVT) on different operating systems for 32bit and 64bit versions. The cross-correlation between pre- and post-switch builds is the same as the auto-correlation for test reruns: the same tests were successful on both sides, the same tests failed for both sides.
>
This is great. Thanks for giving attention to the quality side of this.
A change like this is unlikely to introduce a subtle bug in only one
place. If it breaks things it should be spectacular. So the fact that
nothing is seen yet is a good sign.
-Rob
> Herbert
>
> ---------------------------------------------------------------------
> 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Herbert Dürr <hd...@apache.org>.
[regarding dropping stlport4]
The changes to make the codebase ready for native STL support are done.
Builds with stlport4 enabled will continue to work as before.
I suggest to use the --without-stlport option for all new builds though:
Stlport is a great project, but the versions that OOo depended on had
been released more than ten years ago. The library improved greatly
since then from a feature, performance and standard compliance
perspective. And of course many many bugs have been fixed [1]. In their
stlport5 version they continue to improve significantly.
Platform STLs have been inspired by stlport, improved greatly too and in
the C++11 standardization process divergent views have consolidated. We
can rely on the platform STLs. I agree that the timing of the suggested
switch is not so good but the switch itself is overdue. A major version
change is the right time to do this.
[1] relevant examples of fixes that got into stlport releases newer than
the ones OOo depended on can be seen at e.g.
http://stlport.git.sourceforge.net/git/gitweb.cgi?p=stlport/stlport;a=blob;f=etc/ChangeLog;hb=refs/tags/STLport-STLPORT_4_6
On 2013/05/28 2:38 PM, Rob Weir wrote:
> In theory every fix can cause bugs. But some fixes are more localized
> than others. Fixes with localized impact are easier to test.
> Widespread fixes are harder to test, because more code is potentially
> broken.
The switch was rendered possible by many little changes over the last
couple of months which got our code base more in line with C++11
expectations. Snapshots based on these changes have been and are already
extensively tested by our great QA community. The switch itself is just
another step in evolving towards a high quality release.
Additionally testing has it much easier to find issues introduced by the
switch should there be any. E.g. we have many testers and almost a
thousand automatic tests. They work on different platforms. They cover a
lot of different areas. The risk that a regression in that layer could
remain undetected is very low.
Automated testing ran its 940 autotests (in BVT, FVT, SVT and PVT) on
different operating systems for 32bit and 64bit versions. The
cross-correlation between pre- and post-switch builds is the same as the
auto-correlation for test reruns: the same tests were successful on both
sides, the same tests failed for both sides.
Herbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 28, 2013 at 1:49 AM, Juergen Schmidt <jo...@gmail.com> wrote:
> Am Montag, 27. Mai 2013 um 23:38 schrieb Rob Weir:
>> On Mon, May 27, 2013 at 11:17 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
>> > Hi,
>> >
>> > I would like to discuss our further schedule towards AOO 4.0 and the
>> > problems I see. And I would like to discuss a proposal how to address
>> > these problems.
>> >
>> > We are behind our schedule a little bit and we have identified some
>> > problems regarding the 64bit port on MacOS that I will try to explain
>> > below (hopefully without too many technical details that everybody can
>> > understand it).
>> >
>> > Proposal
>> > ========
>> > - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
>> > (all platforms) asap into trunk and include them in AOO 4.0.
>> >
>> > - Move into showstopper mode next week, beginning with June 3th. Means
>> > we integrate only showstopper flagged issues and new translations. And
>> > potentially new art work if we get a new logo and icons in time.
>> > Deadline for new art work should be June 10th.
>> >
>> > - Intensive QA with the stlport changes to detect potential problems
>>
>> I think this is a huge problem if we're going to introduce changes
>> like this *after* the regression tests have already been run (or are
>> nearly done). Doesn't this totally wreck the QA cycle to introduce
>> widespread changes like this *after* regression tests have been
>> running for weeks?
>>
>> I really cannot support this unless the QA team is comfortable with
>> having their testing invalidated and is willing/able to rerun all of
>> their regression tests.
>>
>> Also, it is not clear to me what the benefit is of merging stlport
>> into the trunk at the last minute?
>>
>>
>> > - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
>> > have integrated already returned translations.
>> >
>> > - Translation deadline will be set to June 14th to have some time for
>> > the integration and further testing. Further translations can we release
>> > at a later time as a special language update release (TBD)
>> >
>> >
>> >
>> > I would still like to keep the end of June date because everything else
>> > looks quite nice and we should give our users the new sidebar.
>> >
>>
>>
>> Would it look any worse if we had a more stable release without the
>> stlport changes?
>>
>> > A shifted release date won't really help us because we will move in the
>> > vacation time and I think it is better to bring the 4.0 version out before.
>> >
>>
>>
>> I agree there. Delaying the release just runs into vacation time. So
>> why rush the stlport?
>>
>> > Once we have solved the mozilla problem for the 64bit version we can
>> > decide if we want release a 4.1 immediately or later together with
>> > further improvements, fixes and further languages.
>> >
>> >
>> > Background Explanation
>> > ======================
>> >
>> > Herbert did a great job with his ongoing work to port AOO to 64bit on
>> > the MacOS platform. This work is mainly triggered and motivated by the
>> > deprecation of some system abi's and the drop of 32 bit Java. In short
>> > we switched to the clang compiler, a new platform SDK, XCode4, replaced
>> > for example atsui API with CoreText, get rid of stlport (on all
>> > platforms) and did many more cleanup that work that were necessary
>> > because of better and/or different compiler/linker behaviour or error
>> > messages etc. Everything looked quite well until we focused on the still
>> > used precompiled older Mozilla libraries. We currently struggle with
>> > porting this stuff to 64 bit and evaluating if we can get rid of them
>> > completely. A complete drop of the mozilla libs would be a further huge
>> > improvement but it is of course a lot of work to understand the code
>> > first and all dependencies and to replace it with some new code... At
>> > the moment we see this on risk for AOO 4.0 and plan to postpone this to 4.1.
>> >
>> > But the drop of the stlport lib is relevant for all platforms and will
>> > introduce a binary incompatibility. The best and only time for such an
>> > incompatible change is a major version. The plan is to extract the
>> > stlport relevant changes and merge them on trunk asap (this week). This
>> > will decouple any further work on the 64bit port and we can release the
>> > 64bit version at any time later (as 4.1) because the 64bit version is
>> > based on a completely new platform on MacOS additionally to the existing
>> > one.
>> >
>> > The 32bit version will be part of the AOO 4.0 release and we will need
>> > this version for backward compatibility on older system anyway. The
>> > 64bit version will run on 10.7 and newer only.
>> >
>> >
>> > I am looking forward to any constructive feedback or concerns.
>>
>> Main concern is the test impact of last minute stlport merge into the trunk.
>>
>> Maybe you can more fully describe the test impact. My impression was
>> the impact would be widespread and could introduce bugs into any part
>> of the product. Is that true? If so, how can we avoid doing a
>> complete regression test pass? As you know that takes several weeks,
>> and that also puts us into vacation season.
>>
>>
>
> I would expect that we have a lot of tests that we do for every new snapshot. If not we have a similar problem because nearly every fix can have side effects and can introduce regressions in other areas. We have seen this many times.
In theory every fix can cause bugs. But some fixes are more localized
than others. Fixes with localized impact are easier to test.
Widespread fixes are harder to test, because more code is potentially
broken.
As you know, this is almost a law of nature. We cannot stop some bug
fixes from requiring widespread testing.
The only thing we can do is coordinate so these high impact bug fixes
so they occur before QA does the regression tests. Otherwise the
regression tests are "invalidated" and should be re-executed.
> The stlport change will ideally have no impact on the user, potentially the whole office behaves faster (not measured yet). Most problems are solved during compile time but nobody can give a guarantee that in certain situations the new stl containers behave slightly different.
The role of QA is to increase the confidence that we are shipping a
release that is free of major defects. After we complete as
regression test cycle that confidence should be higher. After we make
a widespread change that confidence goes down. We don't know for a
fact that defects are actually introduced by the stlport merge. But
until testing occurs the confidence is lower. As with any bug fix
introduced after regression testing our question is the same: What is
the minimum re-test required to restore that confidence?
Regards,
-Rob
> The main reason is the binary incompatibility, but this sounds more serious than it is. It has impact on C++ extension developers only and means that a C++ extension have to be recompiled.
> It worked quite well on MacOS and Linux and we are working on minor issues on Windows because of other compiler errors/warnings.
> Either it worked or a normal test run will show us potential problems.
> We use most often the same kind of containers.
> The timing is not optimal and it is of course a mistake that we don't have extracted the stlport changes from the other changes earlier. But we were focused on solving the main issue that is the 64bit port. And now we are thinking what we can do to move forward and have most flexibility.
>
> Juergen
>>
>> Regards,
>>
>> -Rob
>>
>> > Juergen
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Montag, 27. Mai 2013 um 23:38 schrieb Rob Weir:
> On Mon, May 27, 2013 at 11:17 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
> > Hi,
> >
> > I would like to discuss our further schedule towards AOO 4.0 and the
> > problems I see. And I would like to discuss a proposal how to address
> > these problems.
> >
> > We are behind our schedule a little bit and we have identified some
> > problems regarding the 64bit port on MacOS that I will try to explain
> > below (hopefully without too many technical details that everybody can
> > understand it).
> >
> > Proposal
> > ========
> > - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> > (all platforms) asap into trunk and include them in AOO 4.0.
> >
> > - Move into showstopper mode next week, beginning with June 3th. Means
> > we integrate only showstopper flagged issues and new translations. And
> > potentially new art work if we get a new logo and icons in time.
> > Deadline for new art work should be June 10th.
> >
> > - Intensive QA with the stlport changes to detect potential problems
>
> I think this is a huge problem if we're going to introduce changes
> like this *after* the regression tests have already been run (or are
> nearly done). Doesn't this totally wreck the QA cycle to introduce
> widespread changes like this *after* regression tests have been
> running for weeks?
>
> I really cannot support this unless the QA team is comfortable with
> having their testing invalidated and is willing/able to rerun all of
> their regression tests.
>
> Also, it is not clear to me what the benefit is of merging stlport
> into the trunk at the last minute?
>
>
> > - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> > have integrated already returned translations.
> >
> > - Translation deadline will be set to June 14th to have some time for
> > the integration and further testing. Further translations can we release
> > at a later time as a special language update release (TBD)
> >
> >
> >
> > I would still like to keep the end of June date because everything else
> > looks quite nice and we should give our users the new sidebar.
> >
>
>
> Would it look any worse if we had a more stable release without the
> stlport changes?
>
> > A shifted release date won't really help us because we will move in the
> > vacation time and I think it is better to bring the 4.0 version out before.
> >
>
>
> I agree there. Delaying the release just runs into vacation time. So
> why rush the stlport?
>
> > Once we have solved the mozilla problem for the 64bit version we can
> > decide if we want release a 4.1 immediately or later together with
> > further improvements, fixes and further languages.
> >
> >
> > Background Explanation
> > ======================
> >
> > Herbert did a great job with his ongoing work to port AOO to 64bit on
> > the MacOS platform. This work is mainly triggered and motivated by the
> > deprecation of some system abi's and the drop of 32 bit Java. In short
> > we switched to the clang compiler, a new platform SDK, XCode4, replaced
> > for example atsui API with CoreText, get rid of stlport (on all
> > platforms) and did many more cleanup that work that were necessary
> > because of better and/or different compiler/linker behaviour or error
> > messages etc. Everything looked quite well until we focused on the still
> > used precompiled older Mozilla libraries. We currently struggle with
> > porting this stuff to 64 bit and evaluating if we can get rid of them
> > completely. A complete drop of the mozilla libs would be a further huge
> > improvement but it is of course a lot of work to understand the code
> > first and all dependencies and to replace it with some new code... At
> > the moment we see this on risk for AOO 4.0 and plan to postpone this to 4.1.
> >
> > But the drop of the stlport lib is relevant for all platforms and will
> > introduce a binary incompatibility. The best and only time for such an
> > incompatible change is a major version. The plan is to extract the
> > stlport relevant changes and merge them on trunk asap (this week). This
> > will decouple any further work on the 64bit port and we can release the
> > 64bit version at any time later (as 4.1) because the 64bit version is
> > based on a completely new platform on MacOS additionally to the existing
> > one.
> >
> > The 32bit version will be part of the AOO 4.0 release and we will need
> > this version for backward compatibility on older system anyway. The
> > 64bit version will run on 10.7 and newer only.
> >
> >
> > I am looking forward to any constructive feedback or concerns.
>
> Main concern is the test impact of last minute stlport merge into the trunk.
>
> Maybe you can more fully describe the test impact. My impression was
> the impact would be widespread and could introduce bugs into any part
> of the product. Is that true? If so, how can we avoid doing a
> complete regression test pass? As you know that takes several weeks,
> and that also puts us into vacation season.
>
>
I would expect that we have a lot of tests that we do for every new snapshot. If not we have a similar problem because nearly every fix can have side effects and can introduce regressions in other areas. We have seen this many times.
The stlport change will ideally have no impact on the user, potentially the whole office behaves faster (not measured yet). Most problems are solved during compile time but nobody can give a guarantee that in certain situations the new stl containers behave slightly different.
The main reason is the binary incompatibility, but this sounds more serious than it is. It has impact on C++ extension developers only and means that a C++ extension have to be recompiled.
It worked quite well on MacOS and Linux and we are working on minor issues on Windows because of other compiler errors/warnings.
Either it worked or a normal test run will show us potential problems.
We use most often the same kind of containers.
The timing is not optimal and it is of course a mistake that we don't have extracted the stlport changes from the other changes earlier. But we were focused on solving the main issue that is the 64bit port. And now we are thinking what we can do to move forward and have most flexibility.
Juergen
>
> Regards,
>
> -Rob
>
> > Juergen
> >
> >
> > ---------------------------------------------------------------------
> > 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Rob Weir <ro...@apache.org>.
On Mon, May 27, 2013 at 11:17 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
> Hi,
>
> I would like to discuss our further schedule towards AOO 4.0 and the
> problems I see. And I would like to discuss a proposal how to address
> these problems.
>
> We are behind our schedule a little bit and we have identified some
> problems regarding the 64bit port on MacOS that I will try to explain
> below (hopefully without too many technical details that everybody can
> understand it).
>
> Proposal
> ========
> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> (all platforms) asap into trunk and include them in AOO 4.0.
>
> - Move into showstopper mode next week, beginning with June 3th. Means
> we integrate only showstopper flagged issues and new translations. And
> potentially new art work if we get a new logo and icons in time.
> Deadline for new art work should be June 10th.
>
> - Intensive QA with the stlport changes to detect potential problems
>
I think this is a huge problem if we're going to introduce changes
like this *after* the regression tests have already been run (or are
nearly done). Doesn't this totally wreck the QA cycle to introduce
widespread changes like this *after* regression tests have been
running for weeks?
I really cannot support this unless the QA team is comfortable with
having their testing invalidated and is willing/able to rerun all of
their regression tests.
Also, it is not clear to me what the benefit is of merging stlport
into the trunk at the last minute?
> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> have integrated already returned translations.
>
> - Translation deadline will be set to June 14th to have some time for
> the integration and further testing. Further translations can we release
> at a later time as a special language update release (TBD)
>
>
>
> I would still like to keep the end of June date because everything else
> looks quite nice and we should give our users the new sidebar.
>
Would it look any worse if we had a more stable release without the
stlport changes?
> A shifted release date won't really help us because we will move in the
> vacation time and I think it is better to bring the 4.0 version out before.
>
I agree there. Delaying the release just runs into vacation time. So
why rush the stlport?
> Once we have solved the mozilla problem for the 64bit version we can
> decide if we want release a 4.1 immediately or later together with
> further improvements, fixes and further languages.
>
>
> Background Explanation
> ======================
>
> Herbert did a great job with his ongoing work to port AOO to 64bit on
> the MacOS platform. This work is mainly triggered and motivated by the
> deprecation of some system abi's and the drop of 32 bit Java. In short
> we switched to the clang compiler, a new platform SDK, XCode4, replaced
> for example atsui API with CoreText, get rid of stlport (on all
> platforms) and did many more cleanup that work that were necessary
> because of better and/or different compiler/linker behaviour or error
> messages etc. Everything looked quite well until we focused on the still
> used precompiled older Mozilla libraries. We currently struggle with
> porting this stuff to 64 bit and evaluating if we can get rid of them
> completely. A complete drop of the mozilla libs would be a further huge
> improvement but it is of course a lot of work to understand the code
> first and all dependencies and to replace it with some new code... At
> the moment we see this on risk for AOO 4.0 and plan to postpone this to 4.1.
>
> But the drop of the stlport lib is relevant for all platforms and will
> introduce a binary incompatibility. The best and only time for such an
> incompatible change is a major version. The plan is to extract the
> stlport relevant changes and merge them on trunk asap (this week). This
> will decouple any further work on the 64bit port and we can release the
> 64bit version at any time later (as 4.1) because the 64bit version is
> based on a completely new platform on MacOS additionally to the existing
> one.
>
> The 32bit version will be part of the AOO 4.0 release and we will need
> this version for backward compatibility on older system anyway. The
> 64bit version will run on 10.7 and newer only.
>
>
> I am looking forward to any constructive feedback or concerns.
>
Main concern is the test impact of last minute stlport merge into the trunk.
Maybe you can more fully describe the test impact. My impression was
the impact would be widespread and could introduce bugs into any part
of the product. Is that true? If so, how can we avoid doing a
complete regression test pass? As you know that takes several weeks,
and that also puts us into vacation season.
Regards,
-Rob
> Juergen
>
>
> ---------------------------------------------------------------------
> 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: [RELEASE]: proposed further schedule towards AOO 4.0
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 5/27/13 5:17 PM, Jürgen Schmidt wrote:
> Hi,
>
> I would like to discuss our further schedule towards AOO 4.0 and the
> problems I see. And I would like to discuss a proposal how to address
> these problems.
>
> We are behind our schedule a little bit and we have identified some
> problems regarding the 64bit port on MacOS that I will try to explain
> below (hopefully without too many technical details that everybody can
> understand it).
>
> Proposal
> ========
> - Move MacOS 64 bit version to 4.1 and merge stlport relevant changes
> (all platforms) asap into trunk and include them in AOO 4.0.
>
> - Move into showstopper mode next week, beginning with June 3th. Means
> we integrate only showstopper flagged issues and new translations. And
> potentially new art work if we get a new logo and icons in time.
> Deadline for new art work should be June 10th.
>
> - Intensive QA with the stlport changes to detect potential problems
>
> - Create a AOO 4.0 branch 1 week later, June 10th, where we hopefully
> have integrated already returned translations.
>
> - Translation deadline will be set to June 14th to have some time for
> the integration and further testing. Further translations can we release
> at a later time as a special language update release (TBD)
I have to correct myself because I am probably the bottle neck here and
I will be not available from June 14-17.
But maybe others can help to update at least the pootle server.
Means that I will integrate the translations on June 18th latest. But if
possible please provide them earlier.
Juergen
>
>
>
> I would still like to keep the end of June date because everything else
> looks quite nice and we should give our users the new sidebar.
>
> A shifted release date won't really help us because we will move in the
> vacation time and I think it is better to bring the 4.0 version out before.
>
> Once we have solved the mozilla problem for the 64bit version we can
> decide if we want release a 4.1 immediately or later together with
> further improvements, fixes and further languages.
>
>
> Background Explanation
> ======================
>
> Herbert did a great job with his ongoing work to port AOO to 64bit on
> the MacOS platform. This work is mainly triggered and motivated by the
> deprecation of some system abi's and the drop of 32 bit Java. In short
> we switched to the clang compiler, a new platform SDK, XCode4, replaced
> for example atsui API with CoreText, get rid of stlport (on all
> platforms) and did many more cleanup that work that were necessary
> because of better and/or different compiler/linker behaviour or error
> messages etc. Everything looked quite well until we focused on the still
> used precompiled older Mozilla libraries. We currently struggle with
> porting this stuff to 64 bit and evaluating if we can get rid of them
> completely. A complete drop of the mozilla libs would be a further huge
> improvement but it is of course a lot of work to understand the code
> first and all dependencies and to replace it with some new code... At
> the moment we see this on risk for AOO 4.0 and plan to postpone this to 4.1.
>
> But the drop of the stlport lib is relevant for all platforms and will
> introduce a binary incompatibility. The best and only time for such an
> incompatible change is a major version. The plan is to extract the
> stlport relevant changes and merge them on trunk asap (this week). This
> will decouple any further work on the 64bit port and we can release the
> 64bit version at any time later (as 4.1) because the 64bit version is
> based on a completely new platform on MacOS additionally to the existing
> one.
>
> The 32bit version will be part of the AOO 4.0 release and we will need
> this version for backward compatibility on older system anyway. The
> 64bit version will run on 10.7 and newer only.
>
>
> I am looking forward to any constructive feedback or concerns.
>
> Juergen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org