Hi Tora, very good point you mentioned.
What about different types of release status? For nightly builds or developer snapshots the state is 'unstable'. Why not release languages for final versions in status 'not fully localized tested' or something else. The general functionality should have the same status as the other languages, because most of OOo is language independent. So sanity checks of the languages packs or full install sets should guarantee that the builds are able to install and that general functionality works. But who could do this? And as you wrote correctly, this should be done after the release of the major languages, where we have L10N teams. As Sophie wrote only when the versions are out in the world, we can get the feedback we need to make the languages better and to get the QA contribution for the languages. But again, who should do the releases? Thorsten tora - Takamichi Akiyama wrote:
Hi, Well, i am not interested in stuff such as a process and would like to leave it for someone who likes and/or needs to discuss it. One thing that i would like to mention is that the current L10n QA process is well-made, but impedes proliferation of OOo. Sun and some contributors make localized builds for every release of OOo. A fraction of builds, however, have been released to the market. Most of them are untouched and left in the secret download sites. The word secret means that no casual user knows where he or she can download the not-yet-QAed builds from. Look at the status pages of localized builds and think of current situation. http://qa.openoffice.org/localized/status.html http://www.qatrack.org/ooo/view.php There is *no* OOo available for a bunch of languages. Which is more important at this moment, distributing qualified builds to the local market in return of achieving a OA test or providing world wide users with latest OOo without any additional effort than downloading their localized one. IMHO, the L10n QA process could be tweaked a little bit. To distribute the latest OOo to the world without a big delay from English one, we could define a deadline date of L10n QA test for each release. - Firstly, English one will be released. - Secondly, QAed ones will be released with certification of QAed. - Finally, the rest will be released without certification after the deadline. The fact that there were broken builds several times in the past might be the primary reason why all builds should be tested before release. See the coverage at http://wiki.services.openoffice.org/wiki/OOoRelease1AutomationTestMatrix For the reason that most functionalities of OOo can be considered language independent, we could give a GO to not-yet-completely-tested builds. How about defining a quite simple sanity QA test that covers only installation and releasing the target build if the installation is successful? The purpose why i wanted to mention that was that we would need to think of how to proliferate OOo first, keeping high quality second. Windows Vista and Office system will be available for most languages while OOo are not available for many languags. We will need to take an action without delay. Kind regards, Tora --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
