Difference between revisions of "JA/translation/ChildWorkSpace"
From Apache OpenOffice Wiki
< JA | translation
Line 15: | Line 15: | ||
== そのプロセス・フロー == | == そのプロセス・フロー == | ||
− | + | 課題と、[[CWS]]とリリースの関係を以下に簡単にまとめて提示しておきます。 | |
− | # | + | # 誰かが問題を見つけたり、拡張機能のアイディアを思いつく |
− | # | + | # この問題やアイディアはissuezillaに、まだ載っていない |
− | # | + | # 新しい課題が提出される |
− | # | + | # この課題がテスターや開発者により確認・テストされる |
− | # | + | # この課題が「確認済み」とマークされる |
− | # | + | # 開発部門がこの課題を「新」とマークする |
− | # | + | # 開発部門はそのためのChildWorkSpaceを作る |
− | # | + | # 開発部門はCWSの作業リストにその課題を割り当てる。 |
− | # | + | # 開発部門はこの課題を解決し、その解決策をテストする |
− | # | + | # 開発部門は、そのCWSのコードベースのコードを変更をすることを宣言する |
− | # | + | # 開発部門は、この課題を「処理済み」とマークする |
− | # | + | # 開発部門は、CWS全体が予想通りにきちんと動作するかを確認する |
− | # | + | # 開発部門は、CWSのステータスを「QA部門へ送付可能」とする |
− | # | + | # 開発部門は、この課題をテスト中に指定変更する |
− | # | + | # テスト部門は、リグレッションがないかチェックをし、課題が解決したこととする |
− | # | + | # テストされた課題は「検証済み」とマークされる |
− | # | + | # テスト部門はチャイルドワークスペースのステータスを「QA承認済み」とする |
− | # the CWS gets nominated either by "[[Program_Management|program management]]" or by testing (depending on the release status of the [[MWS]]) | + | # the CWS gets nominated either by "[[Program_Management|program management]]" or by testing (depending on the release status of the [[MWS]])このCWSは、[[Program_Management|プログラム・マネージメント]]あるいはテスト部門のどちらかによって、推奨候補として上げられる(MWSのリリース・ステータスによる) |
− | # "[[Release_Engineering| | + | # "[[Release_Engineering|リリース・エンジニアリング部門]]" はコード変更をマイルストーン・リリースに統合する |
− | # | + | # このCWSステータスを「組み込み済み」となる |
− | # | + | # いくつかのCWSが含まれるマイルストーンをリリースする |
− | # | + | # テスト部門はリリースされた版を再度チェックする |
− | # | + | # テスト部門は、この課題を「解決済み」とマークする |
== FAQ (よくある質問) == | == FAQ (よくある質問) == |
Revision as of 12:53, 14 June 2009
チャイルドワークスペースとは何か?
チャイルドワークスペース (CWS) という概念は、OpenOffice.orgへの修正・変更作業を、より小さく独立なユニットにして体系付けるものです。
この頁はエンドユーザが概観を理解しようとした際、初めて見る頁として作られました。Wikiの「CWS」の項目は、上級貢献者向けの詳細情報を提供しています。
それは課題と、どう関係しているのか?
OpenOffice.orgのコード・ベースは、ある課題が、不具合リポート、拡張リクエスト、あるいは新機能リクエストに分類された場合、結果として、修正・変更が行われることがあります。課題は、 issuezillaと呼ばれるツールで管理されます。
関連する課題はまとめてグループ化され、ひとつのチャイルドワークスペースに割り当てられます。変更されたコードには、CWSに記録された課題リストに関連するバグの修正、機能拡張と新機能が統合されています。
チャイルドワークスペースはエンヴァイロメント・インフォメーション・システム(EIS)というツールで管理されます: このツールでは、それぞれのCWSの詳細が記録されています。例えば、割り当てられたタスクのリスト、リリース予定日時、修正・変更が組み込まれた最初のマイル・ストーン・リリース、さまざまなテスト結果、コード変更のリストなどです。
そのプロセス・フロー
課題と、CWSとリリースの関係を以下に簡単にまとめて提示しておきます。
- 誰かが問題を見つけたり、拡張機能のアイディアを思いつく
- この問題やアイディアはissuezillaに、まだ載っていない
- 新しい課題が提出される
- この課題がテスターや開発者により確認・テストされる
- この課題が「確認済み」とマークされる
- 開発部門がこの課題を「新」とマークする
- 開発部門はそのためのChildWorkSpaceを作る
- 開発部門はCWSの作業リストにその課題を割り当てる。
- 開発部門はこの課題を解決し、その解決策をテストする
- 開発部門は、そのCWSのコードベースのコードを変更をすることを宣言する
- 開発部門は、この課題を「処理済み」とマークする
- 開発部門は、CWS全体が予想通りにきちんと動作するかを確認する
- 開発部門は、CWSのステータスを「QA部門へ送付可能」とする
- 開発部門は、この課題をテスト中に指定変更する
- テスト部門は、リグレッションがないかチェックをし、課題が解決したこととする
- テストされた課題は「検証済み」とマークされる
- テスト部門はチャイルドワークスペースのステータスを「QA承認済み」とする
- the CWS gets nominated either by "program management" or by testing (depending on the release status of the MWS)このCWSは、プログラム・マネージメントあるいはテスト部門のどちらかによって、推奨候補として上げられる(MWSのリリース・ステータスによる)
- "リリース・エンジニアリング部門" はコード変更をマイルストーン・リリースに統合する
- このCWSステータスを「組み込み済み」となる
- いくつかのCWSが含まれるマイルストーンをリリースする
- テスト部門はリリースされた版を再度チェックする
- テスト部門は、この課題を「解決済み」とマークする
FAQ (よくある質問)
課題が処理済みとマークされているのに、最新のマイルストーンに問題として残っていたが、何故だろうか?
- 課題が[解決済み]ではなく、単に「処理済み」とマークしてある場合、最新のマイルストーンではこの処理が含まれていないことを意味する可能性がある。プロセス・フローの個所を読んで理解していただきたいことはー
- CWSの課題は全て解決しなければならない
- 処理済みの課題は検証済みとしなければならない
- 当該CWSは統合しなければならない
- マイルストーンを必ずリリースしなければならない
- もし課題が処理済みかつ解決済みとマークされてあるのに、マイルストーンのクロージングコメントに、そのバグが残っている場合はー
- この課題を再度オープンし、問題を再現する詳細な方法を正確に説明すること。
直した課題が含まれるマイルストーン・リリースは、どれなのか?
- この EIS ツール でCWSの詳細を知ることができる。また、当該 EISエントリーは、課題番号を入力することで得ることができる。
- 解決済みの課題のクロージングコメントには、マイルストーンについての言及があるはずである。
- マイルストーンのリリースノートには、解決した課題の詳細なリストが含まれている。
訳注:issueを課題と訳しましたが、問題点というのも捨てがたい気がしています。
ところで、problemというのは、困ることですが、解決すべきかどうかという意味は入っていません。解決すべき問題とか皆で議論するべきことがissue です。会議をしている時であれば、議題と訳せる場合があります。