バグ / 問題 ¶

バグの報告方法 ¶

まず、それが本当にバグであることを確認してください。Subversion が期待どおりに動作しない場合は、ドキュメントやメーリングリストのアーカイブで、期待どおりに動作すべきであるという証拠を探してください。もちろん、Subversion がデータを破壊してモニターから煙が出たなどの常識的な場合は、自分の判断を信じてください。しかし、確信が持てない場合は、まずユーザーメーリングリスト（users@subversion.apache.org）で質問するか、IRC (irc.libera.chat, チャンネル #svn)（Web インターフェースまたはMatrix) で質問してください。

バグトラッカーで検索して、誰かが既にこのバグを報告していないかどうかも確認する必要があります。

それがバグであり、まだ私たちが知らないということがわかったら、最も重要なことは、簡単な説明と再現レシピを作成することです。たとえば、最初に発見したバグが、10 回のコミットで 5 つのファイルが関係している場合、1 つのファイルと 1 回のコミットだけで発生するようにしてみてください。再現レシピが単純であればあるほど、開発者がバグを再現して修正できる可能性が高くなります。

再現レシピを作成するときは、バグを発生させるために行ったことの散文的な説明だけを書かないでください。代わりに、実行した正確な一連のコマンドとその出力を逐語的に示してください。これを行うには、カットアンドペーストを使用してください。ファイルが関係する場合は、ファイルの名前、および関連性があると思われる場合はその内容も必ず含めてください。最も良いのは、再現レシピをスクリプトとしてパッケージ化することです。これは私たちにとって非常に役立ちます。以下に、このようなスクリプトの例を示します。Unix ライクなシステムおよび Bourne シェル用の repro-template.sh、または Windows シェル用の repro-template.bat (Paolo Compieta による貢献)。他のシステム用の同様のテンプレートスクリプトの貢献も歓迎します。

簡単な正気度チェック: Subversion の最新バージョンを実行していますか? :-) おそらくバグは既に修正されています。最新の Subversion 開発ツリーに対して再現レシピをテストする必要があります。

再現レシピに加えて、バグを再現した環境の完全な説明も必要になります。つまり、

• あなたのオペレーティングシステム
• Subversion のリリースおよび/またはリビジョン
• Subversion をビルドしたコンパイラーと構成オプション
• Subversion に行ったプライベートな変更
• Subversion を使用している Berkeley DB のバージョン（ある場合）
• その他、関連性がある可能性のあるもの。少なすぎるよりは多すぎる情報で誤った判断をしてください。

これがすべて揃ったら、レポートを作成する準備が整いました。まず、バグが何であるかを明確に説明します。つまり、Subversion がどのように動作することを期待していたかと、実際にどのように動作したかを対比して述べます。バグはあなたには明白に見えるかもしれませんが、他の人にはそうではない可能性があるので、推測ゲームを避けるのが最善です。次に、環境の説明と再現レシピを続けます。原因の推測やバグを修正するためのパッチを含めたい場合は、それは素晴らしいことです。パッチの提出ガイドラインを参照してください。

この情報をすべて dev@subversion.apache.org に投稿するか、既に行ったことがあり、問題を提出するように求められた場合は、問題追跡ツールにアクセスして、そこに書かれた手順に従ってください。

ありがとうございます。効果的なバグ報告を提出するには多くの作業が必要であることを承知していますが、優れた報告は開発者の時間を節約し、バグが修正される可能性を高めることができます。

バグの報告先 ¶

• バグが Subversion 自体にある場合は、users@subversion.apache.org にメールを送信してください。バグであることが確認されたら、あなた自身を含めた誰かがそれを問題追跡ツールに入力できます。(または、バグについて確信がある場合は、開発リスト (dev@subversion.apache.org) に直接投稿してください。ただし、確信がない場合は、まずusers@に投稿することをお勧めします。そこで、遭遇した動作が予想されるものかどうかを教えてくれます。)

• バグが APR ライブラリにある場合は、次の両方のメーリングリストに報告してください: dev@apr.apache.org, dev@subversion.apache.org。

• バグが Neon HTTP ライブラリにある場合は、次の宛先に報告してください: neon@webdav.org, dev@subversion.apache.org。

• バグが Apache Serf HTTP ライブラリにある場合は、次の宛先に報告してください: dev@serf.apache.org, dev@subversion.apache.org。

• バグが Apache HTTPD 2.x にある場合は、次の両方のメーリングリストに報告してください: dev@httpd.apache.org, dev@subversion.apache.org。Apache httpd 開発者メーリングリストはトラフィックが多いため、バグレポートの投稿が見落とされる可能性があります。https://httpd.apache.org/bug_report.html でバグレポートを提出することもできます。

• バグがあなたの絨毯にある場合は、抱きしめて暖かくしてください。

マイルストーン管理 ¶

問題追跡ツールのマイルストーンは、Subversion の開発者が取り組みを組織し、Subversion のユーザーベースと相互にコミュニケーションを取る方法の重要な側面です。高レベルの問題のトリアージを行う際に主に使用される一部のマイルストーンを除いて、プロジェクトの問題追跡ツールのマイルストーンは、リリースバージョン番号とそれらのバリエーションを反映して命名される傾向があります。マイルストーンは、問題の状態に応じてわずかに異なる目的で使用されるため、これらの区別を理解することが重要です。

課題のトリアージ ¶

課題が提出されると、特別なマイルストーン "---" （つまり、マイルストーン未設定）に入ります。これは、誰かがそれらを見て、何をすべきかを決定する機会を得るまで、課題が存在する保留領域です。

マイルストーンでソートすると、マイルストーン未設定の課題が最初にリストされます。そして、課題のトリアージは、すべてのオープンな課題（マイルストーン未設定のものから開始）を精査し、どれが今修正するのに十分なほど重要か、どれが別のリリースまで待つことができるか、既存の課題の重複はどれか、既に解決済みの課題はどれかなどを判断するプロセスです。オープンなままになる各課題については、タイプ、サブコンポーネント、プラットフォーム、OS、バージョン、キーワード（存在する場合）などのさまざまなフィールドが適切に設定されていることを確認することも意味します。

プロセスの概要を以下に示します（この例では、1.5が次のリリースであるため、緊急の課題はそこに移動します）。

    for i in issues_marked_as("---"):
      if issue_is_a_dup_of_some_other_issue(i):
        close_as_dup(i)
      elif issue_is_invalid(i):
        # A frequent reason for invalidity is that the reporter
        # did not follow the "buddy system" for filing.
        close_as_invalid(i)
      elif issue_already_fixed(i):
        version = fixed_in_release(i)
        move_to_milestone(i, version)
        close_as_fixed(i)
      elif issue_unreproducible(i):
        close_as_worksforme(i)
      elif issue_is_real_but_we_won't_fix_it(i):
        close_as_wontfix(i)
      elif issue_is_closeable_for_some_other_reason(i):
        close_it_for_that_reason(i)

      # Else issue should remain open, so DTRT with it...

      # Set priority, environment, component, etc, as needed.
      adjust_all_fields_that_need_adjustment(i)

      # Figure out where to put it.
      if issue_is_a_lovely_fantasy(i):
        move_to_milestone(i, "blue-sky")
      if issue_is_not_important_enough_to_block_any_particular_release(i):
        move_to_milestone(i, "nonblocking")
      elif issue_resolution_would_require_incompatible_changes(i):
        move_to_milestone(i, "2.0-consider")
      elif issue_hurts_people_somewhat(i):
        move_to_milestone(i, "1.6-consider")  # or whatever
      elif issue_hurts_people_a_lot(i):
        move_to_milestone(i, "1.5-consider")
      elif issue_hurts_and_hurts_and_should_block_the_release(i):
        move_to_milestone(i, "1.5")

セキュリティ問題の処理方法 ¶