openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <rabas...@gmail.com>
Subject Re: [RELEASE]: proposed further schedule towards AOO 4.0
Date Fri, 31 May 2013 19:04:11 GMT
On May 31, 2013, at 3:16 AM, "Herbert Dürr" <hdu@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


Mime
View raw message