Difference between revisions of "JA/QA/showstopper"

From Apache OpenOffice Wiki
< JA‎ | QA
Jump to: navigation, search
(翻訳の修正)
(翻訳修正)
Line 37: Line 37:
 
* ビルド時にサポートしているAPIが破損する
 
* ビルド時にサポートしているAPIが破損する
 
* ユーザーインターフェース(UI)やヘルプで、翻訳が期限までに提出されているにもかかわらず英語が表示される(マージの問題)
 
* ユーザーインターフェース(UI)やヘルプで、翻訳が期限までに提出されているにもかかわらず英語が表示される(マージの問題)
すべてのissueは、開発者が再現できる必要があります。再現できないものは、開発者は根本原因を見つけることができず、不具合の修正ができません。
+
すべてのissueは、開発者が再現できる必要があります。再現可能なシナリオ(手順)が無いと、開発者は根本的原因を見つけることが困難で、不具合の修正ができません。
  
  
Line 43: Line 43:
 
* 重要でない不具合の一般的な修正
 
* 重要でない不具合の一般的な修正
 
* 一般コードの最適化
 
* 一般コードの最適化
* 一般機能の強化や、追加
+
* 一般機能の強化や追加
  
  
Line 56: Line 56:
 
*** この課題を提案する理由
 
*** この課題を提案する理由
 
*** 件名は、"'推薦/提案'、'課題番号'、'どのリリースに関するストッパーか'"を書きます
 
*** 件名は、"'推薦/提案'、'課題番号'、'どのリリースに関するストッパーか'"を書きます
*** (自信がない場合は、[http://ja.openoffice.org/servlets/ProjectMailingListList qa@ja.openoffice.orgML]で日本語のサポートが受けられるでしょう。)
 
 
* 1~3日で、承認/非承認のメールが[[Release Manager]]から送られてくるでしょう。
 
* 1~3日で、承認/非承認のメールが[[Release Manager]]から送られてくるでしょう。
* もし、自信がなかったり、ストッパーissueかどうかがわからない場合には、メーリングリストで聞いてください。
+
* もし、自信がなかったり、ストッパーissueかどうかがわからない場合には、メーリングリストで聞いてください([http://ja.openoffice.org/servlets/ProjectMailingListList qa@ja.openoffice.orgML]で日本語のサポートが受けられるでしょう)。
  
 
[[Category:Quality Assurance]][[Category:Releases]]
 
[[Category:Quality Assurance]][[Category:Releases]]

Revision as of 15:15, 16 February 2010

http://wiki.services.openoffice.org/wiki/Showstopper

ストッパーブロッカーショーストッパーリリースストッパーリリースブロッカーなどと呼ばれます。これらの不具合/問題は、もっとも重要です。なぜなら、この不具合/問題が修正されるまで、リリースができません。その結果、リリースは1週間もしくはそれ以上遅れます。

A hardware or (especially) software bug that makes an implementation effectively unusable; one that absolutely has to be fixed before development can go on. Opposite in connotation from its original theatrical use, which refers to something stunningly good.
(ハードウェアや(特に)ソフトウェアのバグで事実上使用不可能な物。開発を続ける前に絶対に修正する必要がある。本来は、演劇・公演がとてもすばらしいということを示しますが、それとは逆の意味です。)

-- showstopper as defined in the hacker jargon file


意味

今までのストッパーissueは、リリース候補でのみ報告されていました。しかし、OOo 3.2からこのルールを変更しました。OOo 3.2以降は、一般フェーズのときからストッパーissueの報告を推奨します。このフェーズは、リリースコードラインが一般開発ライン(DEV300) から切り離されたときから始まります。ただ、 ストッパーissueをリリースコードラインに統合するためには、リリースマネージャの承認が必要です。これは、リリースされるまでバージョンを安定させるために必要です。影響が明らかではなく、かつ、リリースに必要なことが明白ではない、大きな変更は許可されません。


ストッパーissueの判断基準

  • 主要機能の リグレッション(Wikipedia)(e-Words:リグレッション)
  • 主要機能のクラッシュ
  • 主要機能の応答停止(フリーズ、ループ)
  • セキュリティの問題
  • プライバシーの問題
  • データの欠落
  • 一つもしくは複数の一般的にサポートするプラットフォーム向けビルドの破壊
  • アクセシビリティ(A11Y)の重大なユーザビリティの問題
  • 法的な問題
  • 翻訳の反映(マージ)の問題


ストッパーissueのサンプル

  • OOoを1つもしくは複数のシステムでインストールできない
  • OOoアプリケーションを起動できない
  • 一般的なファイルを読み込み/書き込み時にOOoがクラッシュする
  • ビルド時に一般的な機能が破損する
  • ODFの検証問題
  • ビルド時にサポートしているAPIが破損する
  • ユーザーインターフェース(UI)やヘルプで、翻訳が期限までに提出されているにもかかわらず英語が表示される(マージの問題)

すべてのissueは、開発者が再現できる必要があります。再現可能なシナリオ(手順)が無いと、開発者は根本的原因を見つけることが困難で、不具合の修正ができません。


ストッパーではないissue

  • 重要でない不具合の一般的な修正
  • 一般コードの最適化
  • 一般機能の強化や追加


ストッパーissueの提案/推薦方法

ストッパーissueとして提案したい不具合を発見した場合は、以下の作業を行う必要があります。

  • 最初に、issueをIssueTrackerに登録
  • releases@openoffice.orgにメールを書く
    • 回答を受け取るために、まずこのメーリングリストに登録してください。
    • メールに次のことを記入してください。
      • issueへのリンクと番号
      • 簡潔な要約
      • この課題を提案する理由
      • 件名は、"'推薦/提案'、'課題番号'、'どのリリースに関するストッパーか'"を書きます
  • 1~3日で、承認/非承認のメールがRelease Managerから送られてくるでしょう。
  • もし、自信がなかったり、ストッパーissueかどうかがわからない場合には、メーリングリストで聞いてください(qa@ja.openoffice.orgMLで日本語のサポートが受けられるでしょう)。
Personal tools
In other languages