On Tue, May 28, 2013 at 1:49 AM, Juergen Schmidt <jogischm...@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 <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 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-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 >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
