Re: [RELEASE]: proposed further schedule towards AOO 4.0
+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 jogischm...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
[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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On May 31, 2013, at 3:16 AM, Herbert Dürr h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On Fri, May 31, 2013 at 12:04 PM, Rob Weir rabas...@gmail.com wrote: On May 31, 2013, at 3:16 AM, Herbert Dürr h...@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++ 11really thanks for posting this. Herbert - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@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
On 5/27/13 11:46 PM, Rob Weir wrote: On Mon, May 27, 2013 at 12:58 PM, janI j...@apache.org wrote: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On 28 May 2013 09:38, Jürgen Schmidt jogischm...@gmail.com wrote: On 5/27/13 11:46 PM, Rob Weir wrote: On Mon, May 27, 2013 at 12:58 PM, janI j...@apache.org wrote: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On 5/28/13 1:03 PM, janI wrote: On 28 May 2013 09:38, Jürgen Schmidt jogischm...@gmail.com wrote: On 5/27/13 11:46 PM, Rob Weir wrote: On Mon, May 27, 2013 at 12:58 PM, janI j...@apache.org wrote: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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
Re: [RELEASE]: proposed further schedule towards AOO 4.0
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On Mon, May 27, 2013 at 06:58:54PM +0200, janI wrote: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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 pgpopiypDdk6H.pgp Description: PGP signature
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Am Montag, 27. Mai 2013 um 18:58 schrieb janI: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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
Re: [RELEASE]: proposed further schedule towards AOO 4.0
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 jogischm...@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
On Mon, May 27, 2013 at 11:17 AM, Jürgen Schmidt jogischm...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On Mon, May 27, 2013 at 12:58 PM, janI j...@apache.org wrote: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [RELEASE]: proposed further schedule towards AOO 4.0
On May 27, 2013, at 2:46 PM, Rob Weir wrote: On Mon, May 27, 2013 at 12:58 PM, janI j...@apache.org wrote: On 27 May 2013 17:17, Jürgen Schmidt jogischm...@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
Re: [RELEASE]: proposed further schedule towards AOO 4.0
Am Montag, 27. Mai 2013 um 23:38 schrieb Rob Weir: On Mon, May 27, 2013 at 11:17 AM, Jürgen Schmidt jogischm...@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
