Proces QA za lokalizirane gradnje
Ta proces je v teku, and as better processes become apparent, we will follow them and change this guideline. Preizkušanje gradenj globoko vključuje projekte QA in Native-Lang. Obvestila, ki kažejo na ta process guideline bo objavljen na teh projektih in tudi pri projektu l10n.
Od kod prihajajo lokalizacije?
Lokalizirane gradnje ustvarja skupnost. Projekt l10n koordinira to aktivnost in vsakdo si lahko ogleda stanje vsake lokalizacije na strani stanja.
Kaj počnemo pri QA?
Smisel preizkušanja QA teh gradenj je reduce verjetnosti, da gradnje ne bodo delovale. 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, ...
Kaj je proces QA?
- Lokalizirane gradnje so na voljo na več mestih. To so:
- 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.
$Revision: 1.3 $
