Hi Alex, saw this mail to late to respond in time (thanks to collab.net for delivering some of my mails with a delay of nearly a full day).
Let me say a few things as the developer involved with the bug. > In the French N-L qa group, we have come across this bug, which has > resurfaced in RC5 : > > http://qa.openoffice.org/issues/show_bug.cgi?id=44445 let me state a thing here for the record which I already wrote in the bug: The problem you encountered is in fact a serious issue, but not the same as issue 44445. In particular, it is no regression. You can reproduce exactly the same problem (which, thanks to Sophie, is now filed as issue 59584) in OOo 2.0, if you spare the primary-key part (see the issue for details). > So my questions are : > > 1) do we pull all of the releases until this is fixed ? My very personal opinion on this: We shouldn't. 2.0.1 was already quite far at the moment you raised this problem, and given that it is a) no regression, and b) is not straight forward to encounter (you need to rename a table column which is referenced in a view), I personally would vote to not delay 2.0.1 for it. > 2) would there be some higher criterion for proceeding with release > despite the fact that this is clearly a severe problem, that had already > been identified in a previous dev version (and fixed at that time) ? As Sophie wrote, the mere number of important fixes already contained in 2.0.1, together with the fact that fixing this particular issue might be non-trivial and thus take some time, might be considerd (IMO) a higher-ranked criterion. > 3) where does quality, and particularly voluntary qa, really stand in > the hierarchy of the release decision process ? I think experience shows that QA, in particular voluntary QA, has a high stand in deciding about a release. Both 2.0 and 2.0.1 tremendously benefited from QA, and last-minute showstoppers found by Sun-external QA. IIRC, both releases were delayed due to such showstoppers. I don't know if there is some formal "QA is allowed to veto a release" agreement, but IMO reality shows that QA has quite some power. For the final decision about a veto: You will always have different opinions on the severity of an issue (see the higher criterions you asked about above), and if it comes to this, there cannot be an abstract "the QA", but some person finally doing the decision. I'd suppose that Andre and Joost fill this role ... > Unfortunately, and perhaps I am mistaken, I have the distinct impression > that the Base module is cast aside somewhat or simply under-represented > in the QA process, possibly because the resources are and have been so > limited for this module. If this is so, then it really is regrettable, > and an error IMHO which will have serious repercussions. The Base module > was developed following user requests for an integrated database > solution. As such, i.e. an integrated part of the OOo product, it should > undergo the same degree of QA scrutiny as the other modules. The > ressources allocated to this project should at least be as commensurate > as the implied scope of potential problems, since this module is one of > the most touted features of the new suite. The QA tests for base are at > present virtually inexistent compared to the other modules I wouldn't say the situation is that bad (okay, that's not backed up by numbers, but only a feeling from working with the Sun-internal Base-QA in the next office :), but I agree that experience shows that Base's QA-coverage could be improved. Side note: But in the past, I also more and more got the impression that a lot of problems are not found by QA testing the product, but by people actively *working* with it, i.e. solving their problems. This is true for not only Base, but the suite as a whole. That said, I believe we might always have this kind of problems found in real-word usage only. This doesn't mean I don't believe in QA. QA does a great job in finding those errors which slipped the developer's attention. But since QA hasn't unlimited resources (as development hasn't), I believe that with a given complexity of the product, only real-world beta testing can find every usage-path ... But hey, I'm digressing ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
