QA Process for Localized Builds

This process is in progress, and as better processes become apparent, we will follow them and change this guideline. The testing of the builds deeply involves the QA and Native-Lang projects. Notices pointing to this process guideline will be posted on those projects and also on the l10n project.

Where do the localizations come from?

Localized builds are created by the community. The l10n project coordinates this activity, and one can view the status of any ongoing localization by checking the status page.

What do we do here, in QA?

The point of having QA test these builds is to reduce the possibility that the builds won't work. They may still be rough, but by going through the QA process, we can at least ensure that we won't be sending out to the world builds that can't be installed, won't work at all, ...

What is the QA process?

• Localized builds are made available at several places. These are:
  • the mirror network under the /contrib/rc directory for most of the builds provided by hamburg release engineering.
  • http://oootranslation.services.openoffice.org/pub/OpenOffice.org/ for language packs or full builds provided by hamburg release engineering.
  • places used by contributors for different platform builds.
• The builds are registered and managed in OpenOffice.org QATrack. The builds are submitted by the QA project, and updated by each build's responsible to indicate the build's current status. Often the responsible is one of the qa responsibles in the Native Lang community.
  For more information about OpenOffice.org QATrack, see the system's Help section.
  There might be a slight delay for the submission of some builds. Therefore, for most current information about the availability of these builds you should subscribe to the relevant mailing lists:
  • releases@openoffice.org
  • dev@porting.openoffice.org
• Native-Lang leads or their delegates assigned to the task of helping QA the builds download the builds and run through a series of tests. This process should begin immediately upon the availability of localized release candidates and should not take more than two weeks from beginning to end. For managing those testcases, test assignemnts and results we use the TCM (Test Case Management) Portal
• An IssueTracker ticket should be filed so as to move the tested builds over to the /localized directory for proper downstream dissemination and to update the pages. Mirrors need to be notified by the Distribution project lead.
  This should be filed as "Task" for Componente "qa", subcomponent "www". Assign it to the default owner and make shure, you name the exact location of the files that have been used for testing.
• Finally, once the mirror network has indicated that the builds have been successfully uploaded into the proper directory, the builds may be announced by the appropriate persons, such as the Native-Lang leads and Community Manager.