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
