Difference between revisions of "JA/translation/ChildWorkSpace"

From Apache OpenOffice Wiki
Jump to: navigation, search
(チャイルドワークスペースとは何か?)
(チャイルドワークスペースとは何か?)
Line 1: Line 1:
 
== チャイルドワークスペースとは何か? ==
 
== チャイルドワークスペースとは何か? ==
  
<b>チャイルドワークスペース</b> (CWS) という概念は、[[OpenOffice.org]]への修正・変更作業を、より小さく独立なユニットにして体系付けるものです。
+
<b>チャイルドワークスペース</b> (CWS) という概念は、[[OpenOffice.org]]への修正・変更作業を、より小さく独立なユニットにして体系付けるものです。
  
 
この頁はエンドユーザが概観を理解しようとした際、初めて見る頁として作られました。Wikiの「[[CWS]]」の項目は、上級貢献者向けの詳細情報を提供しています。
 
この頁はエンドユーザが概観を理解しようとした際、初めて見る頁として作られました。Wikiの「[[CWS]]」の項目は、上級貢献者向けの詳細情報を提供しています。

Revision as of 12:24, 14 June 2009

チャイルドワークスペースとは何か?

チャイルドワークスペース (CWS) という概念は、OpenOffice.orgへの修正・変更作業を、より小さく独立なユニットにして体系付けるものです。

この頁はエンドユーザが概観を理解しようとした際、初めて見る頁として作られました。Wikiの「CWS」の項目は、上級貢献者向けの詳細情報を提供しています。

それは課題と、どう関係しているのか?

OpenOffice.org's code base may be changed as a result of Issues, which can be classified as defect reports, enhancement requests or feature requests. Issues are managed in a tool called issuezilla.

Related issues get grouped together and are assigned to a ChildWorkSpace. The resulting code change consists of bug fixes, enhancements and feature implementations that correspond to the list of issues registered for that CWS.

ChildWorkSpaces are managed in a tool called Environment Information System (EIS): It has all the details about each CWS, e.g. the list of tasks assigned to it, its release target, the first milestone release where it has been integrated, various testing results and the list of code changes.

そのプロセス・フロー

The relationship between an issue, a CWS and a release is described in this simplified process flow:

  1. someone finds a problem or has an enhancement idea
  2. the problem or the idea shouldn't be known in issuezilla yet
  3. a new issue is submitted
  4. the issue is confirmed/tested by testers and/or developers
  5. the issue is marked as "confirmed"
  6. development accepts an issue by marking it as "new"
  7. development creates a ChildWorkSpace
  8. development assigns some issues to the CWS's task list
  9. development solves the issue and tests the solution
  10. development commits the code changes into the CWS's code base
  11. development marks the issue as "fixed"
  12. development checks that the whole CWS works as expected
  13. development changes the CWS status to "Ready for QA"
  14. development reassigns the issues to testing
  15. testing checks for regressions and that the issues are solved
  16. tested issues are marked as "verified"
  17. testing changes the ChildWorkSpace status to "Approved by QA"
  18. the CWS gets nominated either by "program management" or by testing (depending on the release status of the MWS)
  19. "release engineering" integrates the code changes into the a milestone release
  20. the CWS status is changed to "Integrated"
  21. the milestone containing some CWSes is released
  22. testing checks the issues again on the released version
  23. testing marks the issues as "closed"

FAQ (よくある質問)

課題が処理済みとマークされているのに、最新のマイルストーンに問題として残っていたが、何故だろうか?

  • 課題が[解決済み]ではなく、単に「処理済み」とマークしてある場合、最新のマイルストーンではこの処理が含まれていないことを意味する可能性がある。プロセス・フローの個所を読んで理解していただきたいことはー
    • CWSの課題は全て解決しなければならない
    • 処理済みの課題は検証済みとしなければならない
    • 当該CWSは統合しなければならない
    • マイルストーンを必ずリリースしなければならない
  • もし課題が処理済みかつ解決済みとマークされてあるのに、マイルストーンのクロージングコメントに、そのバグが残っている場合はー
    • この課題を再度オープンし、問題を再現する詳細な方法を正確に説明すること。

直した課題が含まれるマイルストーン・リリースは、どれなのか?

  • この EIS ツール でCWSの詳細を知ることができる。また、当該 EISエントリーは、課題番号を入力することで得ることができる。
  • 解決済みの課題のクロージングコメントには、マイルストーンについての言及があるはずである。
  • マイルストーンのリリースノートには、解決した課題の詳細なリストが含まれている。


訳注:issueを課題と訳しましたが、問題点というのも捨てがたい気がしています。 ところで、problemというのは、困ることですが、解決すべきかどうかという意味は入っていません。解決すべき問題とか皆で議論するべきことがissue です。会議をしている時であれば、議題と訳せる場合があります。

Personal tools