Re: [RELEASE]: proposed further schedule towards AOO 4.0

[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
>
>