content/qa/localized/index.html - openoffice-org - Git at Google

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
   <meta http-equiv="content-type" content="text/html; charset=UTF-8">
   <title>QA Process for Localized Builds</title>
 </head>
 <body>
 <h1>QA Process for Localized Builds</h1>
 <p>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 <a href="http://l10n.openoffice.org" target="_blank">l10n</a>
 project.</p>
 <h3>Where do the localizations
 come from?</h3>
 <p>Localized builds are created by
 the community. The <a href="http://l10n.openoffice.org" target="_blank">l10n</a>
 project
 coordinates this activity, and one can view the status of any ongoing
 localization by checking the status page.</p>
 <h3>What do we do here, in QA?</h3>
 <p>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, ...</p>
 <h3>What is the QA process?</h3>
 <ul>
   <li>Localized builds are made
 available at several places. These are:
     <ul>
       <li>the mirror network under
 the /contrib/rc directory for most
 of the builds provided by hamburg release engineering.</li>
       <li><a
  href="http://oootranslation.services.openoffice.org/pub/OpenOffice.org/">http://oootranslation.services.openoffice.org/pub/OpenOffice.org/</a>
 for language packs or full builds provided by hamburg release
 engineering.</li>
       <li>places used by
 contributors for different platform builds.</li>
     </ul>
   <li>The builds are registered and managed in <a href="http://qatrack.services.openoffice.org/">OpenOffice.org QATrack</a>.
   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.<br/>
 For more information about
 OpenOffice.org QATrack, see the system's <a href="http://qatrack.services.openoffice.org/help.php">Help
 section</a>.<br/>
 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:
   <ul>
     <li>releases@openoffice.org</li>
     <li>dev@porting.openoffice.org</li>
   </ul>
 </li>
   <li>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 <a
  href="http://www.sunvirtuallab.com/tcm2/opensource/tcm_index.cgi?tcm_config=newooo">TCM</a>
 (Test Case Management) Portal</li>
   <li>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.<br>
 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.</li>
   <li>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.</li>
 </ul>
 <hr> $Revision: 1.17 $
 </body>
 </html>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	<html>
	<head>
	<meta http-equiv="content-type" content="text/html; charset=UTF-8">
	<title>QA Process for Localized Builds</title>
	</head>
	<body>
	<h1>QA Process for Localized Builds</h1>
	<p>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 <a href="http://l10n.openoffice.org" target="_blank">l10n</a>
	project.</p>
	<h3>Where do the localizations
	come from?</h3>
	<p>Localized builds are created by
	the community. The <a href="http://l10n.openoffice.org" target="_blank">l10n</a>
	project
	coordinates this activity, and one can view the status of any ongoing
	localization by checking the status page.</p>
	<h3>What do we do here, in QA?</h3>
	<p>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, ...</p>
	<h3>What is the QA process?</h3>
	<ul>
	<li>Localized builds are made
	available at several places. These are:
	<ul>
	<li>the mirror network under
	the /contrib/rc directory for most
	of the builds provided by hamburg release engineering.</li>
	<li><a
	href="http://oootranslation.services.openoffice.org/pub/OpenOffice.org/">http://oootranslation.services.openoffice.org/pub/OpenOffice.org/</a>
	for language packs or full builds provided by hamburg release
	engineering.</li>
	<li>places used by
	contributors for different platform builds.</li>
	</ul>
	<li>The builds are registered and managed in <a href="http://qatrack.services.openoffice.org/">OpenOffice.org QATrack</a>.
	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.<br/>
	For more information about
	OpenOffice.org QATrack, see the system's <a href="http://qatrack.services.openoffice.org/help.php">Help
	section</a>.<br/>
	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:
	<ul>
	<li>releases@openoffice.org</li>
	<li>dev@porting.openoffice.org</li>
	</ul>
	</li>
	<li>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 <a
	href="http://www.sunvirtuallab.com/tcm2/opensource/tcm_index.cgi?tcm_config=newooo">TCM</a>
	(Test Case Management) Portal</li>
	<li>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.<br>
	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.</li>
	<li>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.</li>
	</ul>
	<hr> $Revision: 1.17 $
	</body>
	</html>