Charles-H.Schulz wrote:
here is a very, very small and rough draft of the page. As Thomas suggested I put it on the wiki: http://wiki.services.openoffice.org/wiki/NLC/localizedQA
Great. It clearly states what we should do on our localized builds to distribute them to the local market. I am not sure that the following idea could be put in the same page or in the separated page. It is a position of the local test within the development process of OpenOffice.org. Have a look at schedule in the web page http://wiki.services.openoffice.org/wiki/OOoRelease21 . ============================================================== * UI Freeze : October 5th 2006 (New !! all new strings need ... * Feature_freeze : October 12th 2006 (New !! New features ... * Translation update 2.1 start: October 12th * Translation update 2.1 delivery: October 26th, 2006 * code_freeze: November 2nd * l10n CWS builds available: November 2nd * TCM l10n testing on CWS builds: November 2nd - 8th * pre release candidate (en_US only): November 9th 2006 * Last_cws_integration for fixes: November 16th 2006 * release candidate for all languages: November 23th 2006 * release candidate 2 for all languages: December 1st 2006 * Product release: December 12th, 2006 ============================================================== In the list, the local test is positioned in the very end of the process, from release candidate to product release. Many tests had been done before the local test. Each test was done from different perspective of view. So, now we have a question. === What and what for should we test on our local builds to release them? === The question could be divided into several small questions: - What should we test mainly at a period of local test and why? - What should not we test at the moment, which would spend time and make a delay of release process. - (For the next step) How can we eliminate redundancy of test efforts among local communities? The primary functionalities of OpenOffice.org are language independent and identical to every local version. Theoretically, local communities could share test results on the primary functionalities. Answers to the questions could be put somewhere close to the web page. One thing that we could consider: The primary and language independent functionalities had been tested by development team and QA team before our local test. What had not been tested so far? What is difference among local environments? That would be keyboard, input method, font rendering, date-time-currency format, printing to printers that locally purchased, interoperability with competitor's software turned and tweaked to the local market, and so on. We should test language dependent functionalities sometime during the entire development process. But, they obviously should not be done at release test. It is too late and time consuming. But, but, if nobody had tested them at all, some of them should be tested before giving OK to our local builds. Kind regards, Tora --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
