Hi Ruediger, >> - QA should use non-product builds *only*. Yes, I am not kidding about >> this. An assertion which fails indicates a *bug*, that's the very >> original intention of assertions: report bugs. Speaking strictly, >> QA which refuses to use non-product builds refuses to do their job, >> which at least in parts consists of finding bugs. > > Here I strongly disagree. Assertions should be fought before a CWS sees > QA.
Sure. And we should not give a CWS to QA which introduced regressions. Nonetheless, rumors say this happened. > That's something developers should do. Testers have to test what the > customer will get. Qa engineers, sloppily called "testers" :), have the responsibility to ensure quality. A means to point out bugs are assertions. So, testers should use this means, as it helps them doing their job. I see your "testers should test what the customer gets" point, actually, that one was always raised whenever we talked about that topic in the past. See, we had a time where our QA worked on non-product builds (nearly) exclusively. Still, they found the bugs, and I do not know of any case where they did *not* find a bug which they would have found in a product-build. Still, I know *a lot of* bugs which could have been found if more people, explicitly including QA, would have used non-product builds. For instance, one of the stoppers I had for 3.1 would have been found if anybody would simply have *opened the respective dialog* in a non-product build, and would have cared for the assertion which immediately sprung at him. Nobody did - either open the dialog or care for the assertion, whatever ... So, the bottom line is: I think the overall gain, when QA would use non-product builds, is positive: QA would find more bugs than they would miss. >> For OOO320, we stopped providing non-product builds at branch-off day, >> which was about half a year before the product was actually released. >> During a significant part of this time, there still happened heavy >> development on that code line, which is prone to introducing new >> assertion failures, going unnoticed in product builds. > > That's not correct. OOO320 started end of September 2009. Branch date > was code freeze, afterwards only stopper bugs got accepted. > We once decided to restrict non-product builds for code lines where > active development happens, and I still believe that is a good decision. > Release branches as we currently handle them are definitely not the > place for "heavy development". That's my gut feeling only, but: If we would count the lines of code changed in the OOO320 code line, then I believe the sheer number would justify the term "heavy development" ... To back this feeling a little bit: EIS says that there are 113 CWS' with 414 tasks, based on OOO320, targeted for OOo 3.2, in state integrated. Add a few which were still based on DEV300, in the early days of OOO320. No matter whether we can agree to call this "heavy development", I'd say it is enough change happening to justify that we use non-product builds on this code line. As for the decision to not use non-product builds on release code lines: Formerly we had a feature freeze, UI freeze, and code freeze, and the release line was split at code freeze. Today, we have branch-off, which is earlier (relative to the intended release time) than code freeze was. Effectively, this means that a release branch now lives longer than it did formerly. So, at least *one* fact which might influence such a decision has changed, since this decision has been made. So, maybe it is worth re-considering it. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
