Regina Henschel wrote: > Hi all, > > Thorsten Ziehm schrieb: >> Hi Mathias, >> >> Mathias Bauer schrieb: >> >>> More testing on the master(!) would be very welcome. But on the CWS? >>> This will make the "time to master" even longer and then again we are in >>> the vicious cycle I explained in my first posting in this thread. >> >> Yes more testing on Master is welcome, that is true. But most testing >> must be done on CWS. When broken code is in the master code line it >> take too much time to fix it. And then you cannot do Quality Assurance. >> You can make testing, but that has nothing to do with hold a Quality >> standard! >> >> The time to master isn't a problem currently, I think. A general bugfix >> CWS can be 'approved by QA' in 2 days. But when the master is broken, >> you do not know, is the bug in the CWS or in the master. It takes longer >> for checking the problems and this is what we have now. Reduce the time >> to master will come, when the general quality of the master and the CWSs >> is better. >> >> So more testing on CWS is also welcome! >> > > I second the idea of more CWS testing. Remember the new chart module. > There we had a CWS for testing and a lot of bugs were found before the > CWS was integrated in master. There is no need to spread CWS builds with > the mirrors net, but a single server witch holds the builds for Windows, > Linux and Mac is sufficient. You can free the space after the CWS is > integrated.
The problem is that only a few CWS get so much interest that people jump on the CWS testing. My experience with providing CWS builds and asking interested users for testing rather is that nobody did it. And even if people tested them, they usually didn't use the CWS for serious work, they just had a look on the new features. Serious work still is the best regression testing. It's always a good idea to ask users for testing CWS. But if you don't get any help, it's often better to integrate the CWS early, as this enhances the probability that people find bugs in passing. Having CWS lying around for weeks and months (as happened especially for the huge ones in the past) definitely is bad. We always ask developers to have huge or risky changes ready early in the release cycle, so that they can be seen by users. Real life testing done by human beings is the best way to iron out the remaining hard-to-find quirks. But unfortunately "early in the release cycle" quite often means that CWS get in conflict with those of the micro release, and usually the latter get higher priority, both in QA and integration. Perhaps this should be changed? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
